draft-ietf-sipcore-callinfo-rcd-03.txt		draft-ietf-sipcore-callinfo-rcd-04.txt
	Network Working Group C. Wendt		Network Working Group C. Wendt
	Internet-Draft Comcast		Internet-Draft Somos Inc.
	Intended status: Standards Track J. Peterson		Intended status: Standards Track J. Peterson
	Expires: 28 April 2022 Neustar Inc.		Expires: 8 September 2022 Neustar Inc.
	25 October 2021		7 March 2022
	SIP Call-Info Parameters for Rich Call Data		SIP Call-Info Parameters for Rich Call Data
	draft-ietf-sipcore-callinfo-rcd-03		draft-ietf-sipcore-callinfo-rcd-04
	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 a called party for providing more useful		that can be rendered to a 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 28 April 2022.		This Internet-Draft will expire on 8 September 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Revised BSD License text as
	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 Simplified 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. "jcard" Call-Info Token . . . . . . . . . . . . . . . . . . . 4		4. "jcard" Call-Info Token . . . . . . . . . . . . . . . . . . . 5
	5. "call-reason" Call-Info Parameter . . . . . . . . . . . . . . 6		5. "call-reason" Call-Info Parameter . . . . . . . . . . . . . . 6
	6. Usage of jCard and property specific usage . . . . . . . . . 7		6. "jmin" Call-Info Token . . . . . . . . . . . . . . . . . . . 7
	6.1. Usage of URIs in jCard . . . . . . . . . . . . . . . . . 7		7. Usage of jCard and property specific usage . . . . . . . . . 9
	6.2. Usage of multimedia data in jCard . . . . . . . . . . . . 8		7.1. Usage of URIs in jCard . . . . . . . . . . . . . . . . . 9
	6.3. Cardinality . . . . . . . . . . . . . . . . . . . . . . . 9		7.2. Usage of multimedia data in jCard . . . . . . . . . . . . 9
	6.4. Identification properties . . . . . . . . . . . . . . . . 9		7.3. Cardinality . . . . . . . . . . . . . . . . . . . . . . . 10
	6.4.1. "fn" property . . . . . . . . . . . . . . . . . . . . 9		7.4. Identification properties . . . . . . . . . . . . . . . . 11
	6.4.2. "n" property . . . . . . . . . . . . . . . . . . . . 10		7.4.1. "fn" property . . . . . . . . . . . . . . . . . . . . 11
	6.4.3. "nickname" property . . . . . . . . . . . . . . . . . 10		7.4.2. "n" property . . . . . . . . . . . . . . . . . . . . 11
	6.4.4. "photo" property . . . . . . . . . . . . . . . . . . 10		7.4.3. "nickname" property . . . . . . . . . . . . . . . . . 12
	6.5. Delivery Addressing Properties . . . . . . . . . . . . . 11		7.4.4. "photo" property . . . . . . . . . . . . . . . . . . 12
	6.5.1. "adr" property . . . . . . . . . . . . . . . . . . . 11		7.5. Delivery Addressing Properties . . . . . . . . . . . . . 12
	6.6. Communications Properties . . . . . . . . . . . . . . . . 11		7.5.1. "adr" property . . . . . . . . . . . . . . . . . . . 12
	6.6.1. "tel" property . . . . . . . . . . . . . . . . . . . 11		7.6. Communications Properties . . . . . . . . . . . . . . . . 13
	6.6.2. "email" property . . . . . . . . . . . . . . . . . . 12		7.6.1. "tel" property . . . . . . . . . . . . . . . . . . . 13
	6.6.3. "lang" property . . . . . . . . . . . . . . . . . . . 12		7.6.2. "email" property . . . . . . . . . . . . . . . . . . 14
	6.7. Geographical Properties . . . . . . . . . . . . . . . . . 13		7.6.3. "lang" property . . . . . . . . . . . . . . . . . . . 14
	6.7.1. "tz" property . . . . . . . . . . . . . . . . . . . . 13		7.7. Geographical Properties . . . . . . . . . . . . . . . . . 14
	6.7.2. "geo" property . . . . . . . . . . . . . . . . . . . 13		7.7.1. "tz" property . . . . . . . . . . . . . . . . . . . . 14
	6.8. Organizational Properties . . . . . . . . . . . . . . . . 13		7.7.2. "geo" property . . . . . . . . . . . . . . . . . . . 15
	6.8.1. "title" property . . . . . . . . . . . . . . . . . . 14		7.8. Organizational Properties . . . . . . . . . . . . . . . . 15
	6.8.2. "role" property . . . . . . . . . . . . . . . . . . . 14		7.8.1. "title" property . . . . . . . . . . . . . . . . . . 15
	6.8.3. "logo" property . . . . . . . . . . . . . . . . . . . 14		7.8.2. "role" property . . . . . . . . . . . . . . . . . . . 15
	6.8.4. "org" property . . . . . . . . . . . . . . . . . . . 15		7.8.3. "logo" property . . . . . . . . . . . . . . . . . . . 16
	6.9. Explanatory Properties . . . . . . . . . . . . . . . . . 15		7.8.4. "org" property . . . . . . . . . . . . . . . . . . . 16
	6.9.1. "categories" property . . . . . . . . . . . . . . . . 15		7.9. Explanatory Properties . . . . . . . . . . . . . . . . . 16
	6.9.2. "note" property . . . . . . . . . . . . . . . . . . . 15		7.9.1. "categories" property . . . . . . . . . . . . . . . . 16
	6.9.3. "sound" property . . . . . . . . . . . . . . . . . . 16		7.9.2. "note" property . . . . . . . . . . . . . . . . . . . 17
	6.9.4. "uid" property . . . . . . . . . . . . . . . . . . . 16		7.9.3. "sound" property . . . . . . . . . . . . . . . . . . 17
	6.9.5. "url" property . . . . . . . . . . . . . . . . . . . 16		7.9.4. "uid" property . . . . . . . . . . . . . . . . . . . 17
	6.9.6. "version" property . . . . . . . . . . . . . . . . . 17		7.9.5. "url" property . . . . . . . . . . . . . . . . . . . 18
	7. Extension of jCard . . . . . . . . . . . . . . . . . . . . . 17		7.9.6. "version" property . . . . . . . . . . . . . . . . . 18
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17		8. Extension of jCard . . . . . . . . . . . . . . . . . . . . . 18
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
	9.1. SIP Call-Info Header Field Purpose Token Request . . . . 17		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	9.2. SIP Call-Info Header Field Purpose Token Request . . . . 18		10.1. SIP Call-Info Header Field Purpose Token Request . . . . 19
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 18		10.2. SIP Call-Info Header Field Purpose Token Request . . . . 19
	11. Normative References . . . . . . . . . . . . . . . . . . . . 18		11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		12. Normative References . . . . . . . . . . . . . . . . . . . . 19
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	Traditional telephone network signaling protocols have long supported		Traditional telephone network signaling protocols have long supported
	delivering a 'calling name' from the originating side, though in		delivering a 'calling name' from the originating side, though in
	practice, the terminating side is often left to derive a name from		practice, the terminating side is often left to derive a name from
	the calling party number by consulting a local address book or an		the calling party number by consulting a local address book or an
	external database. SIP similarly can carry a 'display-name' in the		external database. SIP similarly can carry a 'display-name' in the
	From header field value from the originating to terminating side,		From header field value from the originating to terminating side,
	though it is an unsecured field that is not commonly trusted. The		though it is an unsecured field that is not commonly trusted and
	same is true of information in the Call-Info header field.		often replaced or ignored. The same is often true of information in
			the Call-Info header fields.
	To allow calling parties to initiate, and called parties to receive,		To allow calling parties to initiate, and called parties to receive,
	a more comprehensive, deterministic, and extensible rich call data		a more comprehensive, deterministic, and extensible rich call data
	for incoming calls, we describe new tokens for the SIP [RFC3261]		for incoming calls, we describe new tokens for the SIP [RFC3261]
	Call-Info header field and a corresponding "purpose" parameter. We		Call-Info header field and a corresponding "purpose" parameter. We
	also define a new parameter of Call-Info designed for carrying a		also define a new parameter of Call-Info designed for carrying a
	"reason" value. For this document, depending on the policies of the		"reason" value. For this document, depending on the policies of the
	communications system, calling parties could either be the end user		communications system, calling parties could either be the end user
	device or an originating service provider, and called parties could		device or an originating service provider, and called parties could
	also similarly be an end user device or the terminating service		also similarly be an end user device or the terminating service
	skipping to change at page 4, line 22 ¶		skipping to change at page 4, line 24 ¶
	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 BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Overview		3. Overview
	The Call-Info header field, defined in [RFC3261] Section 20.9,		The Call-Info header field, defined in [RFC3261] Section 20.9,
	defines a purpose parameter currently with "info", "icon", and "card"		defines a purpose parameter currently with "info", "icon", and "card"
	tokens. This document defines one new purpose value and one new		tokens. This document defines two new purpose values and one new
	generic parameter for Call-Info.		generic parameter for Call-Info.
	The value "jcard" is to be used to associate rich call data related		The first purpose value defined is "jcard" and is used to associate
	to the identity of the calling party in the form of a jCard		rich call data related to the identity of the calling party in the
	[RFC7095]. While there is a "card" token that is already defined		form of a jCard [RFC7095]. While there is a "card" token that is
	with similar purpose, there are two primary reasons for the		already defined with similar purpose, there are two primary reasons
	definition and usage of jCard and the use of JSON over the XML based		for the definition and usage of jCard and the use of JSON over the
	vCard [RFC2426]. First, JSON has become the default and is generally		XML based vCard [RFC2426]. First, JSON has become the default and is
	the widely accepted optimally supported format for transmission,		generally the widely accepted optimally supported format for
	parsing, and manipulation of data on IP networks. Second, jCard has		transmission, parsing, and manipulation of data on IP networks.
	also been defined in [I-D.ietf-stir-passport-rcd] and has been		Second, jCard has also been defined in [I-D.ietf-stir-passport-rcd]
	adopted by PASSporT [RFC8225] because of the usage of JSON Web Tokens		and has been adopted by PASSporT [RFC8225] because of the usage of
	(JWT) [RFC7519].		JSON Web Tokens (JWT) [RFC7519].
	A generic parameter for "call-reason" is to be used to provide a		A generic parameter for "call-reason" is to be used to provide a
	string or other object that is used to convey the intent or reason		string or other object that is used to convey the intent or reason
	the caller is calling to help the called party understand better the		the caller is calling to help the called party understand better the
	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.
			The second purpose value defined is "jmin" and is intended to be a
			minimal call-info URI specifically for purposes where call-info does
			not point to any structured information via URI, but is used to carry
			parameters either defined in this document or future documents.
	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 field is defined to include a URI, where here		The Call-Info header field is defined to include a URI, where here
	the resource pointed to by the URI is a jCard JSON object [RFC7095].		the resource pointed to by the URI is a jCard JSON object [RFC7095].
	The web server serving this file MUST use the MIME media type for		The MIME media type set for the JSON text MUST be set as application/
	JSON text as application/json with a default encoding of UTF-8		json with a default encoding of UTF-8 [RFC4627]. A jCard also MAY be
	[RFC4627]. A jCard also MAY be carried in the body of the SIP		carried in the body of the SIP request bearing this Call-Info via the
	request bearing this Call-Info via the "cid" URI scheme [RFC2392].		"cid" URI scheme [RFC2392]. Alternatively, the URI MUST define the
	Alternatively, the URI MUST define the use HTTPS or a transport that		use HTTPS or a transport that can validate the integrity of the
	can validate the integrity of the source of the resource as well as		source of the resource as well as the transport channel through which
	the transport channel through which the resource is retrieved.		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/qbranch.json>;purpose=jcard		Call-Info: <https://example.com/qbranch.json>;purpose=jcard
	An example contents of a URL linked jCard JSON file is shown as		An example contents of a URL linked jCard JSON file is shown as
	follows:		follows:
	["vcard",		["vcard",
	[		[
	skipping to change at page 6, line 44 ¶		skipping to change at page 6, line 44 ¶
	Content-ID: <12155551000@example.com>		Content-ID: <12155551000@example.com>
	["vcard",[["version",{},"text","4.0"],["fn",{},"text","Q Branch"],		["vcard",[["version",{},"text","4.0"],["fn",{},"text","Q Branch"],
	["org",{},"text","MI6;Q Branch Spy Gadgets"],["photo",{},"uri","ht		["org",{},"text","MI6;Q Branch Spy Gadgets"],["photo",{},"uri","ht
	tps://example.com/photos/quartermaster-256x256.png"],["logo",{},"u		tps://example.com/photos/quartermaster-256x256.png"],["logo",{},"u
	ri","https://example.com/logos/mi6-256x256.jpg"],["logo",{},"uri",		ri","https://example.com/logos/mi6-256x256.jpg"],["logo",{},"uri",
	"https://example.com/logos/mi6-64x64.jpg"]]]		"https://example.com/logos/mi6-64x64.jpg"]]]
	5. "call-reason" Call-Info Parameter		5. "call-reason" Call-Info Parameter
	In addition to the jCard value defined here, this specification also		This specification also defines a parameter of the Call-Info header
	defines a generic parameter of the Call-Info header called "call-		called "call-reason". The "call-reason" parameter is intended to
	reason". The "call-reason" parameter is intended to convey a short		convey a short textual message suitable for display to an end user
	textual message suitable for display to an end user during call		during call alerting. As a general guideline, this message SHOULD be
	alerting. As a general guideline, this message SHOULD be no longer		no longer than 64 characters; displays that support this
	than 64 characters; displays that support this specification may be		specification may be forced to truncate messages that cannot fit onto
	forced to truncate messages that cannot fit onto a screen. This		a screen. This message conveys the caller's intention in contacting
	message conveys the caller's intention in contacting the callee. It		the callee. It is an optional parameter, and the sender of a SIP
	is an optional parameter, and the sender of a SIP request cannot		request cannot guarantee that its display will be supported by the
	guarantee that its display will be supported by the terminating		terminating endpoint. The manner in which this reason is set by the
	endpoint. The manner in which this reason is set by the caller is		caller is outside the scope of this specification.
	outside the scope of this specification.
	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>;purpose=jcard;		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		Refer to the next section that extends call-reason and, in
	that could be reliably processed automatically. Future versions of		particular, discusses reasoning for the use of "call-reason"
	this specification may explore ways to provide a structured data		parameter versus considering "jinfo" with an included "call-reason"
	object in place of a textual string to support things like		key value.
	internationalization or categories of reason that can be parsed by
	machines.
	6. Usage of jCard and property specific usage		6. "jmin" Call-Info Token
			This specification defines a token for the Call-Info header field
			called "jmin". The "jmin" call-info URI is intended to address the
			need for scenarios where there it is not needed to use the URI value
			of call-info but only necessary to use defined call-info parameters,
			one example being the "call-reason" parameter defined in this
			document. The URI referenced value by "jmin" is defined as a minimal
			JSON formatted object that MUST be the specific value "{}". The JSON
			object "{}" is a valid JSON object per [RFC8259] but specifically
			contains no keys or values. The MIME media type for this minimal
			JSON object text MUST be set as application/json with a default
			encoding of UTF-8 [RFC4627]. The "jmin" minimal JSON object string
			MAY be carried in the body of the SIP request bearing this Call-Info
			via the "cid" URI scheme [RFC2392]. Alternatively, the URI MUST
			define the use HTTPS or a transport that can validate the integrity
			of the source of the resource as well as the transport channel
			through which the resource is retrieved.
			We define this minimal JSON object for the express purpose of being a
			valid URI that will not break implementations that are not
			implementing this specification that reference the URI per procedures
			defined in [RFC3261] Section 20.9. However, for implementations that
			do support this specification, because the value referenced by the
			URI MUST be "{}", as an optimization, implementations of this
			specification MAY consider it a shortcut to not reference the URI and
			trust that the value referenced will always be "{}".
			An example of a Call-Info header field using "jmin" purpose and call-
			reason parameter is:
			Call-Info: <https://example.com/min.json>;purpose=jmin;
			call-reason="For your ears only"
			The resource referenced by the URL for the above example would be a
			file containing:
			{}
			An example SIP INVITE using the "cid" URI scheme equivalent to the
			above example is as follows.
			INVITE sip:alice@example.com SIP/2.0
			Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
			To: Alice <sip:alice@example.com>
			From: Bob <sip:12155551000@example.com;user=phone>;tag=1928301774>
			Call-ID: a84b4c76e66710
			Call-Info: <cid:12155551000@example.com>;purpose=jmin;call-reason=
			"For your ears only"
			CSeq: 314159 INVITE
			Max-Forwards: 70
			Date: Fri, 25 Sep 2015 19:12:25 GMT
			Contact: <sip:12155551000@gateway.example.com>
			Content-Type: multipart/mixed; boundary=boundary1
			Content-Length: ...
			--boundary1
			Content-Type: application/sdp
			v=0
			o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
			s=Session SDP
			c=IN IP4 pc33.atlanta.example.com
			t=0 0
			m=audio 49172 RTP/AVP 0
			a=rtpmap:0 PCMU/8000
			--boundary1
			Content-Type: application/json
			Content-ID: <12155551000@example.com>
			{}
			7. Usage of jCard and property specific usage
	Beyond the definition of the specific properties or JSON arrays		Beyond the definition of the specific properties or JSON arrays
	associated with each property. This specification defines a few		associated with each property. This specification defines a few
	rules above and beyond [RFC7095] specific to the use of jCard for		rules above and beyond [RFC7095] specific to the use of jCard for
	Call-Info and Rich Call Data making sure there is a minimum level of		Call-Info and Rich Call Data making sure there is a minimum level of
	supported properties that every implementation of this specification		supported properties that every implementation of this specification
	should adhere to. This includes support for interpreting the value		should adhere to. This includes support for interpreting the value
	of this property and the ability to render in some appropriate form		of this property and the ability to render in some appropriate form
	the display capabilities of common telephone devices, as well as		the display capabilities of common telephone devices, as well as
	apps, and also includes requirements specific to either textual		apps, and also includes requirements specific to either textual
	displays and graphics capable displays.		displays and graphics capable displays.
	6.1. Usage of URIs in jCard		7.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 (unless updated by any		usage of "jcl" as a URI to the jCard itself (unless updated by any
	future extensions of this specification) MUST not contain any URI		future extensions of this specification) 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, and therefore MUST
	be enforced by the client to fail verification or not render content		be enforced by the client to not follow those URI references or not
	to the user if any URI are present in that specific URI linked		render that content to the user if any URI are present in that
	content. The purpose of this is to control the security and more		specific URI linked content. The purpose of this is to control the
	specifically align with the content integrity mechanism defined in		security and more specifically align with the content integrity
	[I-D.ietf-stir-passport-rcd]. It is the belief of the authors that		mechanism defined in [I-D.ietf-stir-passport-rcd]. It is the belief
	there isn't a scenario that deeper URI references would be required		of the authors that there isn't a scenario that deeper URI references
	or even supported by the current set of properties for the typical		would be required or even supported by the current set of properties
	use of jCard properties, but because jCard is extensible, this rule		for the typical use of jCard properties, but because jCard is
	is set to restrict further extension without the proper consideration		extensible, this rule is set to restrict further extension without
	of security and integrity properties of both Call-Info usage as well		the proper consideration of security and integrity properties of both
	as the Rich Call Data and STIR signing of the data		Call-Info usage as well as the Rich Call Data and STIR signing of the
	[I-D.ietf-stir-passport-rcd], [RFC8224].		data [I-D.ietf-stir-passport-rcd], [RFC8224].
	6.2. Usage of multimedia data in jCard		7.2. Usage of multimedia data in jCard
	There are a few cases where jCards incorporate URIs or directly		There are a few cases where jCards incorporate URIs or directly
	include via Base64 encoding of digital images and sounds. We specify		include via Base64 encoding of digital images and sounds. We specify
	a few recommended conventions to facilitate more consistent support		a few recommended conventions to facilitate more consistent support
	of the successful rendering of these images.		of the successful rendering of these images.
	For images, such as for the photo and logo properties, the default		For images, such as for the photo and logo properties, the default
	image formats should be png or jpg. These files are mostly commonly		image formats SHOULD be png or jpg. These files are mostly commonly
	used to support 24-bit RGB images which should consequently be the		used to support 24-bit RGB images which should consequently be the
	default. There are some older telephone devices that may only		default. There are some older telephone devices that may only
	support bmp type of images with lower bit-range (e.g. 16-bit or 8-bit		support bmp type of images with lower bit-range (e.g. 16-bit or 8-bit
	or 1-bit), also with potentially only grayscale or 1-bit black and		or 1-bit), also with potentially only grayscale or 1-bit black and
	white color displays. These exceptions are considered optional to		white color displays. These exceptions are should considered
	support.		optional to support or even recommended not to support and at least
			at the time of writing this document are becoming increasingly rare
			(i.e. typically displays on devices are either color or color-aware
			graphical displays that support png or jpg formats or exclusively
			textual displays).
	In addition, vector images are increasingly popular in their use for		In addition, vector images are increasingly popular in their use for
	icons and the need for scalable images without having to send		icons and the need for scalable images without having to send
	multiple resolutions. SVG format [W3C SVG 1.1 or higher] has gained		multiple resolutions. SVG format and [W3C SVG 1.2 Tiny or higher]
	wide support, as of the writing of this document, as a common format		specifically appropriate for this specification has gained wide
	for vector images and should be supported as an additional default		support as of the writing of this document, as a common format for
	format supported by devices that support this specification.		vector images and should be supported as an additional default format
			for devices that support this specification.
	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 on to the end of a file name, before the file extension		concatenated on to the end of a file name, before the file extension
	that signals the height and width of the image to the end device for		that signals the height and width of the image to the end device for
	the convenience of determining the appropriate resolution to retrieve		the convenience of determining the appropriate resolution to retrieve
	without the need to retrieve all the image files. It is also		without the need to retrieve all the image files. It is also
	recommended that images are square ratio formatted with equal height		recommended that images are square ratio formatted with equal height
	and width and with a power of two value for the number of pixels		and width and with a power of two value for the number of pixels
	(e.g. 32x32, 128x128, 512x512). The format of the string should be		(e.g. 32x32, 128x128, 512x512). The format of the string should be
	"filename-HxW" where filename represents the unique string		"filename-HxW" where filename represents the unique string
	representing the file and H represents the height in pixels and W		representing the file and H represents the height in pixels and W
	represents the width in pixels. If the file is not to be rendered		represents the width in pixels.
	using the default 24-bit RGB pixel format, additionally the string
	can be extended to include bit depth and number of colors. That		Because this is a complex and often debated topic that has evolved
	string should be formatted as "filename-HxW-bd-c", where bd is the		over the many years of advances in image coding and display
	bit depth (e.g. 1, 8, 16) and c represents number of color channels		technologies, we likely suggest relying on either future
	which should either be 1 or 3. Note: 32-bit/RGBA color format is		specifications or industry forum specifications that might correspond
	specifically not recommended for this document because transparency		to supporting particular classes of devices to further define how
	would not be clear how to render for display.		URIs can 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 wav
	files, although the usage of sound is not well defined in this		files, although the usage of sound is not well defined in this
	specification as, for example, a special ring tone for a particular		specification as, for example, a special ring tone for a particular
	caller, and future documents should consider both usage and potential		caller, and future documents should consider both usage and potential
	security risks of playing sounds that are not specifically authorized		security risks of playing sounds that are not specifically authorized
	by a device user.		by a device user.
	6.3. Cardinality		7.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 |
	+-------------+--------------------------------------------------+		+-------------+--------------------------------------------------+
	| 1 | Exactly one instance per jCard MUST be present. |		| 1 | Exactly one instance per jCard MUST be present. |
	| *1 | Exactly one instance per jCard MAY be present. |		| *1 | Exactly one instance per jCard MAY be present. |
	| 1* | One or more instances per jCard MUST be present. |		| 1* | One or more instances per jCard MUST be present. |
	| * | One or more instances per jCard MAY be present. |		| * | One or more instances per jCard MAY be present. |
	+-------------+--------------------------------------------------+		+-------------+--------------------------------------------------+
	6.4. Identification properties		7.4. Identification properties
	These types are used to capture information associated with the		These types are used to capture information associated with the
	identification and naming of the entity associated with the jCard.		identification and naming of the entity associated with the jCard.
	They are initially defined in [RFC6350], but the following list of		They are initially defined in [RFC6350], but the following list of
	properties included and repeated in this Section is a subset of the		properties included and repeated in this Section is a subset of the
	properties defined for jCard with properties selected for this		properties defined for jCard with properties selected for this
	document that have relevance to telephone and messaging applications.		document that have relevance to telephone and messaging applications.
	jCard is an extensible object and therefore, there may also be future		jCard is an extensible object and therefore, there may also be future
	specifications that extend the set of properties that may be relevant		specifications that extend the set of properties that may be relevant
	to the set of communications applications that utilize this		to the set of communications applications that utilize this
	specification.		specification.
	6.4.1. "fn" property		7.4.1. "fn" property
	The "fn" property has the intent of providing a formatted text		The "fn" property has the intent of providing a formatted text
	corresponding to the name of the object the jCard represents.		corresponding to the name of the object the jCard represents.
	Reference [RFC6350] Section 6.2.1.		Reference [RFC6350] Section 6.2.1.
	Value type: A single text value.		Value type: A single text value.
	Cardinality: 1*		Cardinality: 1*
	Example:		Example:
	["fn", {}, "text", "Mr. John Q. Public\, Esq."]		["fn", {}, "text", "Mr. John Q. Public\, Esq."]
	6.4.2. "n" property		7.4.2. "n" property
	The "n" property has the intent of providing the components of the		The "n" property has the intent of providing the components of the
	name of the object the jCard represents. Reference [RFC6350]		name of the object the jCard represents. Reference [RFC6350]
	Section 6.2.2.		Section 6.2.2.
	Value type: A single structured text value. Each component can have		Value type: A single structured text value. Each component can have
	multiple values.		multiple values.
	Cardinality: *1		Cardinality: *1
	Example:		Example:
	["n", {}, "text", "Public;John;Quinlan;Mr.;Esq."]		["n", {}, "text", "Public;John;Quinlan;Mr.;Esq."]
	["n", {}, "text", "Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."]		["n", {}, "text", "Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."]
	6.4.3. "nickname" property		7.4.3. "nickname" property
	The "nickname" property has the intent of providing the text		The "nickname" property has the intent of providing the text
	corresponding to the nickname of the object the jCard represents.		corresponding to the nickname of the object the jCard represents.
	Reference [RFC6350] Section 6.2.3.		Reference [RFC6350] Section 6.2.3.
	Value type: One or more text values separated by a COMMA character		Value type: One or more text values separated by a COMMA character
	(U+002C).		(U+002C).
	Cardinality: *		Cardinality: *
	Example:		Example:
	["nickname", {}, "text", "Robbie"]		["nickname", {}, "text", "Robbie"]
	["nickname", {}, "text", "Jim,Jimmie"]		["nickname", {}, "text", "Jim,Jimmie"]
	["nickname", {}, "text", "TYPE=work:Boss"]		["nickname", {}, "text", "TYPE=work:Boss"]
	6.4.4. "photo" property		7.4.4. "photo" property
	The "photo" property has the intent of supplying an image or		The "photo" property has the intent of supplying an image or
	photograph information that annotates some aspect of the object the		photograph information that annotates some aspect of the object the
	jCard represents. Reference [RFC6350] Section 6.2.4.		jCard represents. Reference [RFC6350] Section 6.2.4.
	In addition to the definition of jCard, and to promote		In addition to the definition of jCard, and to promote
	interoperability and proper formatting and rendering of images, the		interoperability and proper formatting and rendering of images, the
	photo SHOULD correspond to a square image size of the sizes 128x128,		photo SHOULD correspond to a square image size of the sizes 128x128,
	256x256, 512x512, or 1024x1024 pixels.		256x256, 512x512, or 1024x1024 pixels.
	Value type: A single URI.		Value type: A single URI.
	Cardinality: *		Cardinality: *
	Example:		Example:
	["photo", {}, "uri", "http://www.example.com/jqpublic-256x256.png"]		["photo", {}, "uri", "http://www.example.com/jqpublic-256x256.png"]
	6.5. Delivery Addressing Properties		7.5. Delivery Addressing Properties
	These properties are concerned with information related to the		These properties are concerned with information related to the
	delivery addressing or label for the jCard object.		delivery addressing or label for the jCard object.
	6.5.1. "adr" property		7.5.1. "adr" property
	The "adr" property has the intent of providing the delivery address		The "adr" property has the intent of providing the delivery address
	of the object the jCard represents. Reference [RFC6350]		of the object the jCard represents. Reference [RFC6350]
	Section 6.3.1.		Section 6.3.1.
	Value type: A single structured text value, separated by the		Value type: A single structured text value, separated by the
	SEMICOLON character (U+003B).		SEMICOLON character (U+003B).
	Cardinality: *		Cardinality: *
	Example:		Example:
	["adr", {"type":"work"}, "text",		["adr", {"type":"work"}, "text",
	["", "", "3100 Massachusetts Avenue NW", "Washington", "DC",		["", "", "3100 Massachusetts Avenue NW", "Washington", "DC",
	"20008", "USA"]		"20008", "USA"]
	6.6. Communications Properties		7.6. Communications Properties
	These properties describe information about how to communicate with		These properties describe information about how to communicate with
	the object the jCard represents.		the object the jCard represents.
	6.6.1. "tel" property		7.6.1. "tel" property
	The "tel" property has the intent of providing the telephone number		The "tel" property has the intent of providing the telephone number
	for telephony communication of the object the jCard represents.		for telephony communication of the object the jCard represents.
	Reference [RFC6350] Section 6.4.1.		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 alternate telephone number or other related telephone numbers		provide alternate telephone number or other related telephone numbers
	for other uses.		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 potential instances of the
	skipping to change at page 12, line 27 ¶		skipping to change at page 14, line 5 ¶
	value. It is expected that the URI scheme will be "tel", as		value. It is expected that the URI scheme will be "tel", as
	specified in [RFC3966], but other schemes MAY be used.		specified in [RFC3966], but other schemes MAY be used.
	Cardinality: *		Cardinality: *
	Example:		Example:
	["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri",		["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri",
	"tel:+1-202-555-1000"]		"tel:+1-202-555-1000"]
	["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"]		["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"]
	6.6.2. "email" property		7.6.2. "email" property
	The "email" property has the intent of providing the electronic mail		The "email" property has the intent of providing the electronic mail
	address for communication of the object the jCard represents.		address for communication of the object the jCard represents.
	Reference [RFC6350] Section 6.4.2.		Reference [RFC6350] Section 6.4.2.
	Value type: A single text value.		Value type: A single text value.
	Cardinality: *		Cardinality: *
	Example:		Example:
	["email", {"type":"work"}, "text", "jqpublic@xyz.example.com"]		["email", {"type":"work"}, "text", "jqpublic@xyz.example.com"]
	["email", {"pref":"1"}, "text", "jane_doe@example.com"]		["email", {"pref":"1"}, "text", "jane_doe@example.com"]
	6.6.3. "lang" property		7.6.3. "lang" property
	The "lang" property has the intent of providing the language(s) that		The "lang" property has the intent of providing the language(s) that
	may be used for contacting of the object the jCard represents.		may be used for contacting of the object the jCard represents.
	Reference [RFC6350] Section 6.4.4.		Reference [RFC6350] Section 6.4.4.
	Value type: A single language-tag value.		Value type: A single language-tag value.
	Cardinality: *		Cardinality: *
	Example:		Example:
	["lang", {"type":"work", "pref":"1"}, "language-tag", "en"]		["lang", {"type":"work", "pref":"1"}, "language-tag", "en"]
	["lang", {"type":"work", "pref":"2"}, "language-tag", "fr"]		["lang", {"type":"work", "pref":"2"}, "language-tag", "fr"]
	["lang", {"type":"home"}, "language-tag", "fr"]		["lang", {"type":"home"}, "language-tag", "fr"]
	6.7. Geographical Properties		7.7. Geographical Properties
	These properties are concerned with information associated with		These properties are concerned with information associated with
	geographical positions or regions associated with the object the		geographical positions or regions associated with the object the
	jCard represents.		jCard represents.
	6.7.1. "tz" property		7.7.1. "tz" property
	The "tz" property has the intent of providing the time zone of the		The "tz" property has the intent of providing the time zone of the
	object the jCard represents. Reference [RFC6350] Section 6.5.1.		object the jCard represents. Reference [RFC6350] Section 6.5.1.
	Note: the up-to-date reference for where time-zone names are		Note: the up-to-date reference for where time-zone names are
	maintained is, at the authoring of this document, at this web		maintained is, at the authoring of this document, at this web
	address, https://www.iana.org/time-zones.		address, https://www.iana.org/time-zones.
	Value type: The default is a single text value. It can also be reset		Value type: The default is a single text value. It can also be reset
	to a single URI or utc-offset value.		to a single URI or utc-offset value.
	skipping to change at page 13, line 28 ¶		skipping to change at page 15, line 4 ¶
	object the jCard represents. Reference [RFC6350] Section 6.5.1.		object the jCard represents. Reference [RFC6350] Section 6.5.1.
	Note: the up-to-date reference for where time-zone names are		Note: the up-to-date reference for where time-zone names are
	maintained is, at the authoring of this document, at this web		maintained is, at the authoring of this document, at this web
	address, https://www.iana.org/time-zones.		address, https://www.iana.org/time-zones.
	Value type: The default is a single text value. It can also be reset		Value type: The default is a single text value. It can also be reset
	to a single URI or utc-offset value.		to a single URI or utc-offset value.
	Cardinality: *		Cardinality: *
	Example:		Example:
	["tz", {}, "text", "Raleigh/North America"]		["tz", {}, "text", "Raleigh/North America"]
	6.7.2. "geo" property		7.7.2. "geo" property
	The "geo" property has the intent of providing the global positioning		The "geo" property has the intent of providing the global positioning
	of the object the jCard represents. Reference [RFC6350]		of the object the jCard represents. Reference [RFC6350]
	Section 6.5.2.		Section 6.5.2.
	Value type: A single URI.		Value type: A single URI.
	Cardinality: *		Cardinality: *
	Example:		Example:
	["geo", {}, "uri", "geo:37.386013,-122.082932"]		["geo", {}, "uri", "geo:37.386013,-122.082932"]
	6.8. Organizational Properties		7.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.
	6.8.1. "title" property		7.8.1. "title" property
	The "title" property has the intent of providing the position or job		The "title" property has the intent of providing the position or job
	of the object the jCard represents. Reference [RFC6350]		of the object the 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"]
	6.8.2. "role" property		7.8.2. "role" property
	The "role" property has the intent of providing the position or job		The "role" property has the intent of providing the position or job
	of the object the jCard represents. Reference [RFC6350]		of the object the 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"]
	6.8.3. "logo" property		7.8.3. "logo" property
	The "logo" property has the intent of specifying a graphic image of a		The "logo" property has the intent of specifying a graphic image of a
	logo associated with the object the jCard represents. Reference		logo associated with the object the jCard represents. Reference
	[RFC6350] Section 6.6.3.		[RFC6350] 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...>"]
	6.8.4. "org" property		7.8.4. "org" property
	The "org" property has the intent of specifying the organizational		The "org" property has the intent of specifying the organizational
	name and units of the object the jCard represents. Reference		name and units of the object the jCard represents. Reference
	[RFC6350] Section 6.6.2.		[RFC6350] Section 6.6.2.
	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"]
	6.9. Explanatory Properties		7.9. Explanatory Properties
	These properties are concerned with additional explanations, such as		These properties are concerned with additional explanations, such as
	that related to informational notes or revisions specific to the		that related to informational notes or revisions specific to the
	jCard.		jCard.
	6.9.1. "categories" property		7.9.1. "categories" property
	The "categories" property has the intent of specifying application		The "categories" property has the intent of specifying application
	category information about the object the jCard represents.		category information about the object the jCard represents.
	Reference [RFC6350] Section 6.7.1.		Reference [RFC6350] Section 6.7.1.
	Value type: One or more text values separated by a COMMA character		Value type: One or more text values separated by a COMMA character
	(U+002C).		(U+002C).
	Cardinality: *		Cardinality: *
	Example:		Example:
	["categories", {}, "text", "TRAVEL AGENT"]		["categories", {}, "text", "TRAVEL AGENT"]
	["categories", {}, "text", "INTERNET,IETF,INDUSTRY"]		["categories", {}, "text", "INTERNET,IETF,INDUSTRY"]
	6.9.2. "note" property		7.9.2. "note" property
	The "note" property has the intent of specifying supplemental		The "note" property has the intent of specifying supplemental
	information or a comment about the object the jCard represents.		information or a comment about the object the jCard represents.
	Reference [RFC6350] Section 6.7.2.		Reference [RFC6350] Section 6.7.2.
	Value type: A single text value.		Value type: A single text value.
	Cardinality: *		Cardinality: *
	Example:		Example:
	["note", {}, "text", "This fax number is operational 0800 to 1715		["note", {}, "text", "This fax number is operational 0800 to 1715
	EST\, Mon-Fri."]		EST\, Mon-Fri."]
	6.9.3. "sound" property		7.9.3. "sound" property
	The "sound" property has the intent of specifying a digital sound		The "sound" property has the intent of specifying a digital sound
	content information that annotates some aspect of the object the		content information that annotates some aspect of the object the
	jCard represents. This property is often used to specify the proper		jCard represents. This property is often used to specify the proper
	pronunciation of the name property value of the jCard. Reference		pronunciation of the name property value of the jCard. Reference
	[RFC6350] Section 6.7.5.		[RFC6350] Section 6.7.5.
	Value type: A single URI.		Value type: A single URI.
	Cardinality: *		Cardinality: *
	Example:		Example:
	["sound", {}, "uri", "http://www.example.com/pub/logos/abccorp.mp3"]		["sound", {}, "uri", "http://www.example.com/pub/logos/abccorp.mp3"]
	["sound", {}, "uri", "data:audio/basic;base64,MIICajCCAdOgAwIBAgICBE		["sound", {}, "uri", "data:audio/basic;base64,MIICajCCAdOgAwIBAgICBE
	AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm		AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
	ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0		ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
	<...the remainder of base64-encoded data...>"]		<...the remainder of base64-encoded data...>"]
	6.9.4. "uid" property		7.9.4. "uid" property
	The "uid" property has the intent of specifying a globally unique		The "uid" property has the intent of specifying a globally unique
	identifier corresponding to the object the jCard represents.		identifier corresponding to the object the jCard represents.
	Reference [RFC6350] Section 6.7.6.		Reference [RFC6350] Section 6.7.6.
	Value type: A single URI value. It MAY also be reset to free-form		Value type: A single URI value. It MAY also be reset to free-form
	text.		text.
	Cardinality: *1		Cardinality: *1
	Example:		Example:
	["uid", {}, "uri", "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"]		["uid", {}, "uri", "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"]
	6.9.5. "url" property		7.9.5. "url" property
	The "url" property has the intent of specifying a uniform resource		The "url" property has the intent of specifying a uniform resource
	locator associated with the object the jCard represents. Reference		locator associated with the object the jCard represents. Reference
	[RFC6350] Section 6.7.8.		[RFC6350] Section 6.7.8.
	There is potential security and privacy implications of providing		There is potential security and privacy implications of providing
	URLs with telephone calls. The end client receiving a jCard with a		URLs with telephone calls. The end client receiving a jCard with a
	URL property MUST only display the URL and not automatically follow		URL property MUST only display the URL and not automatically follow
	the URL or provide automatic preview of the URL, and generally		the URL or provide automatic preview of the URL, and generally
	provide good practices in making it clear to the user it is their		provide good practices in making it clear to the user it is their
	skipping to change at page 17, line 16 ¶		skipping to change at page 18, line 32 ¶
	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"]
	6.9.6. "version" property		7.9.6. "version" property
	The "version" property MUST be included and is intended to specify		The "version" property MUST be included and is intended to specify
	the version of the vCard specification used to format this vCard.		the version of the vCard specification used to format this vCard.
	Reference [RFC6350] Section 6.7.9.		Reference [RFC6350] Section 6.7.9.
	Value type: A single text value.		Value type: A single text value.
	Cardinality: 1		Cardinality: 1
	Example:		Example:
	["version", {}, "text", "4.0"]		["version", {}, "text", "4.0"]
	7. Extension of jCard		8. Extension of jCard
	Part of the intent of the usage of jCard is that it has its own		Part of the intent of the usage of jCard is that it has its own
	extensibility properties where new properties can be defined to relay		extensibility properties where new properties can be defined to relay
	newly defined information related to a caller. This capability is		newly defined information related to a caller. This capability is
	inherently supported as part of standard extensibility. However,		inherently supported as part of standard extensibility. However,
	usage of those new properties should be published and registered		usage of those new properties should be published and registered
	following [RFC7095] Section 3.6 or new specifications.		following [RFC7095] Section 3.6 or new specifications.
	8. Acknowledgements		9. Acknowledgements
	We would like to thank David Hancock and other members of the STIR		We would like to thank David Hancock, Alec Fenichel and other members
	working group for helpful suggestions and comments for the creation		of the SIPCORE and STIR working group for helpful suggestions and
	of this draft.		comments for the creation of this draft.
	9. IANA Considerations		10. IANA Considerations
	9.1. SIP Call-Info Header Field Purpose Token Request		10.1. SIP Call-Info Header Field Purpose Token Request
	[this RFC] defines the "jcard" token for use as a new token in the		[this RFC] defines the "jcard" token for use as a new token in the
	Call-Info header in the "Header Field Parameters and Parameter		Call-Info header in the "Header Field Parameters and Parameter
	Values" registry defined by [RFC3968].		Values" registry defined by [RFC3968].
	+--------------+----------------+-------------------+------------+		+--------------+----------------+-------------------+------------+
	| Header Field | Parameter Name | Predefined Values | Reference |		| Header Field | Parameter Name | Predefined Values | Reference |
	+--------------+----------------+-------------------+------------+		+--------------+----------------+-------------------+------------+
	| Call-Info | jcard | No | [this RFC] |		| Call-Info | jcard | No | [this RFC] |
	+--------------+----------------+-------------------+------------+		+--------------+----------------+-------------------+------------+
	9.2. SIP Call-Info Header Field Purpose Token Request		10.2. SIP Call-Info Header Field Purpose Token Request
	[this RFC] defines the "call-reason" generic parameter for use as a		[this RFC] defines the "call-reason" generic parameter for use as a
	new parameter in the Call-Info header in the "Header Field Parameters		new parameter in the Call-Info header in the "Header Field Parameters
	and Parameter Values" registry defined by [RFC3968]. The parameter's		and Parameter Values" registry defined by [RFC3968]. The parameter's
	token is "call-reason" and it takes the value of a quoted string.		token is "call-reason" and it takes the value of a quoted string.
	10. Security Considerations		11. 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. SIP and Call-		a person necessarily entails certain privacy risks. SIP and Call-
	Info has no particular confidentiality requirement, as the		Info has no particular confidentiality requirement, as the
	information sent in SIP is in the clear anyway. Transport-level		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.
	11. Normative References		The security framework of signing and providing integrity to this
			data should be followed [I-D.ietf-stir-passport-rcd], with the idea
			that the use of constraints and other certificate based associations
			should be considered. This includes considerations around
			information about the calling party being generally constant vs per
			call data being more temporal. This also includes the relationship
			that certificates with constraints presents to how they relate to
			each other and how that information is managed, protected, and
			associated with the correct call corresponding to a calling party.
			12. 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-13, 9 September 2021,		stir-passport-rcd-14, 25 October 2021,
	<https://www.ietf.org/archive/id/draft-ietf-stir-passport-		<https://www.ietf.org/archive/id/draft-ietf-stir-passport-
	rcd-13.txt>.		rcd-14.txt>.
	[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/info/rfc2119>.		<https://www.rfc-editor.org/info/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/info/rfc2392>.		<https://www.rfc-editor.org/info/rfc2392>.
	skipping to change at page 20, line 19 ¶		skipping to change at page 21, line 41 ¶
	[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/info/rfc8224>.		<https://www.rfc-editor.org/info/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/info/rfc8225>.		<https://www.rfc-editor.org/info/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/info/rfc8259>.
	Authors' Addresses		Authors' Addresses
	Chris Wendt		Chris Wendt
	Comcast		Somos Inc.
	Comcast Technology Center
	Philadelphia, PA 19103,
	United States of America		United States of America
	Email: chris-ietf@chriswendt.net		Email: chris-ietf@chriswendt.net
	Jon Peterson		Jon Peterson
	Neustar Inc.		Neustar Inc.
	1800 Sutter St Suite 570		1800 Sutter St Suite 570
	Concord, CA 94520,		Concord, CA 94520,
	United States of America		United States of America
	Email: jon.peterson@neustar.biz		Email: jon.peterson@neustar.biz
End of changes. 71 change blocks.
	166 lines changed or deleted		259 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/