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/