draft-ietf-jmap-jscontact-vcard-00.txt		draft-ietf-jmap-jscontact-vcard-01.txt
	jmap M. Loffredo		jmap M. Loffredo
	Internet-Draft IIT-CNR/Registro.it		Internet-Draft IIT-CNR/Registro.it
	Intended status: Informational R. Stepanek		Intended status: Informational R. Stepanek
	Expires: January 14, 2021 FastMail		Expires: April 14, 2021 FastMail
	July 13, 2020		October 11, 2020
	JSContact: Converting from and to vCard		JSContact: Converting from and to vCard
	draft-ietf-jmap-jscontact-vcard-00		draft-ietf-jmap-jscontact-vcard-01
	Abstract		Abstract
	This document provides informational guidance for converting the		This document provides informational guidance for converting the
	contact card defined by JSContact specification, namely JSCard, from		contact card defined by JSContact specification, namely JSCard, from
	and to vCard.		and to vCard.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 January 14, 2021.		This Internet-Draft will expire on April 14, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 18 ¶		skipping to change at page 3, line 18 ¶
	2.10.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . 32		2.10.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . 32
	2.10.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . 33		2.10.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . 33
	2.10.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . 34		2.10.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . 34
	2.11. Additional Clarifications about Mapping . . . . . . . . . 35		2.11. Additional Clarifications about Mapping . . . . . . . . . 35
	2.11.1. Media type . . . . . . . . . . . . . . . . . . . . . 35		2.11.1. Media type . . . . . . . . . . . . . . . . . . . . . 35
	2.11.2. Timezone . . . . . . . . . . . . . . . . . . . . . . 35		2.11.2. Timezone . . . . . . . . . . . . . . . . . . . . . . 35
	2.12. Extended Properties . . . . . . . . . . . . . . . . . . . 36		2.12. Extended Properties . . . . . . . . . . . . . . . . . . . 36
	2.13. vCard Unmatched Properties . . . . . . . . . . . . . . . 36		2.13. vCard Unmatched Properties . . . . . . . . . . . . . . . 36
	2.14. JSCard Required Properties . . . . . . . . . . . . . . . 36		2.14. JSCard Required Properties . . . . . . . . . . . . . . . 36
	2.15. JSCard Unmatched Properties . . . . . . . . . . . . . . . 36		2.15. JSCard Unmatched Properties . . . . . . . . . . . . . . . 36
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37		3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 37		4. Implementation Status . . . . . . . . . . . . . . . . . . . . 37
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . 37		4.1. CNR . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	5.1. Normative References . . . . . . . . . . . . . . . . . . 37		5. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	5.2. Informative References . . . . . . . . . . . . . . . . . 38		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38		6.1. Normative References . . . . . . . . . . . . . . . . . . 38
			6.2. Informative References . . . . . . . . . . . . . . . . . 39
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
	1. Introduction		1. Introduction
	1.1. Motivation		1.1. Motivation
	The JSContact specification [draft-ietf-jmap-jscontact] has been		The JSContact specification [draft-ietf-jmap-jscontact] has been
	defined to represent contact card information as a more efficient		defined to represent contact card information as a more efficient
	alternative to vCard [RFC6350] and its JSON-based version named jCard		alternative to vCard [RFC6350] and its JSON-based version named jCard
	[RFC7095].		[RFC7095].
	skipping to change at page 6, line 25 ¶		skipping to change at page 6, line 25 ¶
	with the full name translations in various languages regardless of		with the full name translations in various languages regardless of
	the presence of the ALTID parameter. Each translation corresponds to		the presence of the ALTID parameter. Each translation corresponds to
	a different entry of the "localizations" map (Figure 3).		a different entry of the "localizations" map (Figure 3).
	2.2.2. N and NICKNAME		2.2.2. N and NICKNAME
	Both the N and NICKNAME elements are converted into equivalent items		Both the N and NICKNAME elements are converted into equivalent items
	of the "name" array (Figure 3):		of the "name" array (Figure 3):
	o the N components are transformed into related "NameComponent"		o the N components are transformed into related "NameComponent"
	objects as reported in Table 1. Name components SHOULD be ordered		objects as presented in Table 1. Name components SHOULD be
	such that their values joined by whitespace produce a valid full		ordered such that their values joined by whitespace produce a
	name of this entity;		valid full name of this entity;
	o Each NICKNAME element is mapped onto an object whose "type" member		o Each NICKNAME element is mapped onto an object whose "type" member
	is set to "nickname"		is set to "nickname"
	+--------------------+--------------+		+--------------------+--------------+
	| N component | "type" value |		| N component | "type" value |
	+--------------------+--------------+		+--------------------+--------------+
	| Honorific Prefixes | prefix |		| Honorific Prefixes | prefix |
	| Given Names | personal |		| Given Names | personal |
	| Family Names | surname |		| Family Names | surname |
	skipping to change at page 10, line 17 ¶		skipping to change at page 10, line 17 ¶
	TBD		TBD
	2.3. Delivery Addressing Properties		2.3. Delivery Addressing Properties
	2.3.1. ADR		2.3.1. ADR
	An ADR element is represented as an "Address" object in the		An ADR element is represented as an "Address" object in the
	"addresses" array (Figure 6).		"addresses" array (Figure 6).
	The ADR components are transformed into the "Address" members as		The ADR components are transformed into the "Address" members as
	reported in Table 2.		presented in Table 2.
	+------------------+----------------+		+------------------+----------------+
	| ADR component | Address member |		| ADR component | Address member |
	+------------------+----------------+		+------------------+----------------+
	| p.o. box | postOfficeBox |		| p.o. box | postOfficeBox |
	| extended address | extension |		| extended address | extension |
	| street address | street |		| street address | street |
	| locality | locality |		| locality | locality |
	| region | region |		| region | region |
	| postal code | postcode |		| postal code | postcode |
	skipping to change at page 36, line 31 ¶		skipping to change at page 36, line 31 ¶
	If an extended property is a resource, JSCard already allows to		If an extended property is a resource, JSCard already allows to
	represent it by setting the "type" member to "other" and specifying a		represent it by setting the "type" member to "other" and specifying a
	value for the "labels" map.		value for the "labels" map.
	Any other property supporting a custom feature MAY be added and its		Any other property supporting a custom feature MAY be added and its
	name MUST be prefixed with a specific domain name to avoid conflict,		name MUST be prefixed with a specific domain name to avoid conflict,
	e.g. "example.com/customprop".		e.g. "example.com/customprop".
	2.13. vCard Unmatched Properties		2.13. vCard Unmatched Properties
	Any vCard property or parameter that doesn't have a direct		Any vCard property that doesn't have a direct counterpart in
	counterpart in JSContact is treated as an extended property. The		JSContact is treated as an extended property whose name is prefixed
	following mapping rules MUST be applied:		by "ietf.org/rfc6350/".
	o an unmatched property is converted into an extended property whose
	name is prefixed by "ietf.org/rfc6350/"
	o an unmatched parameter is converted into an extended property
	whose name is prefixed by "ietf.org/rfc6350/<vCard property>/"
	In both cases, the resulting names MUST be in lowercase.		The resulting name MUST be in lowercase.
	2.14. JSCard Required Properties		2.14. JSCard Required Properties
	While converting a vCard into a JSCard, only the topmost "uid" member		While converting a vCard into a JSCard, only the topmost "uid" member
	is required.		is required.
	2.15. JSCard Unmatched Properties		2.15. JSCard Unmatched Properties
	The "preferredContactMethod" member doesn't match any vCard element.		The "preferredContactMethod" member doesn't match any vCard element.
	3. IANA Considerations		3. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	4. Security Considerations		4. Implementation Status
	This document doesn't report any security consideration.		NOTE: Please remove this section and the reference to RFC 7942 prior
			to publication as an RFC.
	5. References		This section records the status of known implementations of the
			protocol defined by this specification at the time of posting of this
			Internet-Draft, and is based on a proposal described in [RFC7942].
			The description of implementations in this section is intended to
			assist the IETF in its decision processes in progressing drafts to
			RFCs. Please note that the listing of any individual implementation
			here does not imply endorsement by the IETF. Furthermore, no effort
			has been spent to verify the information presented here that was
			supplied by IETF contributors. This is not intended as, and must not
			be construed to be, a catalog of available implementations or their
			features. Readers are advised to note that other implementations may
			exist.
	5.1. Normative References		According to RFC 7942, "this will allow reviewers and working groups
			to assign due consideration to documents that have the benefit of
			running code, which may serve as evidence of valuable experimentation
			and feedback that have made the implemented protocols more mature.
			It is up to the individual working groups to use this information as
			they see fit".
			4.1. CNR
			Responsible Organization: National Research Council (CNR) of Italy
			Location: https://github.com/consiglionazionaledellericerche/
			jscontact-tools
			Description: This implementation includes tools for JSContact
			creation, validation, serialization/deserialization and conversion
			from vCard, xCard and jCard.
			Level of Maturity: This is an "alpha" test implementation.
			Coverage: This implementation includes all of the features
			described in this specification.
			Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it
			5. Security Considerations
			This document doesn't present any security consideration.
			6. References
			6.1. Normative References
	[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>.
	[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,		[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
	DOI 10.17487/RFC6350, August 2011,		DOI 10.17487/RFC6350, August 2011,
	<https://www.rfc-editor.org/info/rfc6350>.		<https://www.rfc-editor.org/info/rfc6350>.
	skipping to change at page 37, line 49 ¶		skipping to change at page 38, line 38 ¶
	<https://www.rfc-editor.org/info/rfc6715>.		<https://www.rfc-editor.org/info/rfc6715>.
	[RFC6869] Salgueiro, G., Clarke, J., and P. Saint-Andre, "vCard		[RFC6869] Salgueiro, G., Clarke, J., and P. Saint-Andre, "vCard
	KIND:device", RFC 6869, DOI 10.17487/RFC6869, February		KIND:device", RFC 6869, DOI 10.17487/RFC6869, February
	2013, <https://www.rfc-editor.org/info/rfc6869>.		2013, <https://www.rfc-editor.org/info/rfc6869>.
	[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,		[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
	DOI 10.17487/RFC7095, January 2014,		DOI 10.17487/RFC7095, January 2014,
	<https://www.rfc-editor.org/info/rfc7095>.		<https://www.rfc-editor.org/info/rfc7095>.
			[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
			Code: The Implementation Status Section", BCP 205,
			RFC 7942, DOI 10.17487/RFC7942, July 2016,
			<https://www.rfc-editor.org/info/rfc7942>.
	[RFC8605] Hollenbeck, S. and R. Carney, "vCard Format Extensions:		[RFC8605] Hollenbeck, S. and R. Carney, "vCard Format Extensions:
	ICANN Extensions for the Registration Data Access Protocol		ICANN Extensions for the Registration Data Access Protocol
	(RDAP)", RFC 8605, DOI 10.17487/RFC8605, May 2019,		(RDAP)", RFC 8605, DOI 10.17487/RFC8605, May 2019,
	<https://www.rfc-editor.org/info/rfc8605>.		<https://www.rfc-editor.org/info/rfc8605>.
	5.2. Informative References		6.2. Informative References
	[draft-ietf-jmap-jscontact]		[draft-ietf-jmap-jscontact]
	"JSContact: A JSON representation of contact data",		"JSContact: A JSON representation of contact data",
	<https://datatracker.ietf.org/doc/draft-ietf-jmap-		<https://datatracker.ietf.org/doc/draft-ietf-jmap-
	jscontact/>.		jscontact/>.
	[time-zones]		[time-zones]
	"Time Zone Database", <https://www.iana.org/time-zones>.		"Time Zone Database", <https://www.iana.org/time-zones>.
	[uri-schemes]		[uri-schemes]
End of changes. 14 change blocks.
	29 lines changed or deleted		67 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/