Foreword

This document updates the following specifications:

I-D.calconnect-vobject-vformat, The vObject Model and vFormat Syntax
RFC 6350, vCard version 4.0
RFC 5545, Internet Calendaring and Scheduling Core Object Specification (iCalendar)
RFC 7953, Calendar Availability Extensions

This work is produced by the CalConnect TC-VCARD and TC-CALENDAR committees.

Introduction

vCard IETF RFC 6350 and iCalendar IETF RFC 5545 are standards compliant to the vObject data model Internet-Draft draft-calconnect-vobject-vformat-00.

These standards are used worldwide and require proper certain localization elements suitable for multi-cultural use.

Previously, the only internationalization method for vCard IETF RFC 6350 and iCalendar IETF RFC 5545 standards was the language property parameter (3.2.10).

This document:

defines additional internationalization features for the vObject data model, including a separate property parameter that denotes the script used in a property value, and a method to specify pronunciation of a property value
defines realization methods of vObject internationalization in vFormat

The methods described in this document are intended to be used by vObject-compliant standards, such as vCard 4.0 IETF RFC 6350 and iCalendar IETF RFC 5545.

This is a work product of the CalConnect TC-VCARD CalConnect TC VCARD and TC-CALENDAR CalConnect TC CALENDAR committees.

vObject — Internationalization

1. Scope

Methods described in this document are intended to be used by vObject-compliant standards, such as vCard 4.0 IETF RFC 6350 and iCalendar IETF RFC 5545.

2. Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

IETF RFC 5545, Internet Engineering Task Force (committee). Internet Calendaring and Scheduling Core Object Specification (iCalendar). 2009. RFC Publisher. https://www.rfc-editor.org/info/rfc5545.

IETF RFC 6350, PERREAULT, S. and Internet Engineering Task Force. vCard Format Specification. 2011. RFC Publisher. https://www.rfc-editor.org/info/rfc6350.

Internet-Draft draft-calconnect-vobject-vformat-00, TSE, Ronald, Peter TAM, Cyrus DABOO and Kenneth MURCHISON. The vObject Model and vFormat Syntax. 2018. https://datatracker.ietf.org/doc/html/draft-calconnect-vobject-vformat-00.

3. Terms and definitions

For the purposes of this document, the following terms and definitions apply.

3.1. General

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 IETF RFC 2119 IETF RFC 8174 when, and only when, they appear in all capitals, as shown here.

The key words “Private Use”, “Experimental Use”, “Hierarchical Allocation”, “First Come First Served”, “Expert Review”, “Specification Required”, “RFC Required”, “IETF Review”, “Standards Action” and “IESG Approval” in this document are to be interpreted as described in 4.

Notation in this document is described in ABNF IETF RFC 5234 as used by IETF RFC 6350.

Definitions from IETF RFC 6350 apply to this specification except when explicitly overridden.

All names of properties, property parameters, enumerated property values, and property parameter values are case-insensitive. However, all property values are case-sensitive, unless otherwise stated.

3.2. Definitions

For the purposes of this document, the following terms and definitions apply.

3.2.1. transliteration

operation which consists of representing the characters (3.1.4.02) of an entirely alphabetical (3.1.5.16) character or alphanumeric character writing system (3.1.6.01) by the characters of the conversion alphabet

[SOURCE: 3.1.6.11]

3.2.2. script

particular graphic representation or class of representations of a set of characters used to write one or more languages

[SOURCE: 3.1.6.02]

3.2.3. phonetic transcription

representation or modelling of spoken language based on the sound system of the respective language 3.5

4. Property Parameter Usage Clarification: LANGUAGE

This section clarifies the intent of the LANGUAGE property parameter in IETF RFC 5545 and IETF RFC 6350 to be for the identification of the language used in the property value where the parameter is specified.

The IETF RFC 5646 defined language-tag allows specification of multiple attributes (called “subtags”) in addition to just language. Its basic form includes:

a mandatory language subtag, using a language identifier from ISO 639 (-2, -3) (called a “primary” or “extended” language subtag)
an optional script subtag, using a script identifier from ISO 15924
an optional region subtag, using country codes listed in ISO 3166 or a UN numeric code
one or more, optional, variant and extension subtags defined in the IANA language subtag registry.

In practical usage of vObject standards, including IETF RFC 5545 and IETF RFC 6350, it is determined that the combinatorial enumeration of non-language subtags often cause unnecessary confusion in interpretation and parsing, especially when the registry contain variant and extension subtags that either conflict in semantics or have overly restrictive in their supported prefixes.

This document therefore clarifies the intent of 3.2.10 and 5.1, such that the LANGUAGE property parameter SHOULD only support the mandatory language subtag.

Other subtags MAY be supplied as specified in IETF RFC 5646, but they are purely for informational purposes not used in the vObject specification.

Namespace
Property parameter name: LANGUAGE
Purpose: To specify the language used in the property value.
Value type: LANGUAGE-TAG 4.8
Description: As provided above.

4.1. vFormat Implementation of LANGUAGE

The value of the LANGUAGE property parameter is re-defined as shown below.

Format definition

languageparam = "LANGUAGE" "=" language *(subpart)

language = iso-639-3-code / iso-639-2-code
          ; a 2-alpha or 3-alpha language code
          ; defined in ISO 639

subpart  = "-" *alphanum
           ; all other subparts unsupported

Figure 1

Examples

N;LANGUAGE=en:Miyazaki;Hayao;;;
N;LANGUAGE=jp:宮崎;駿;;;

Figure 2

5. Property Parameter: SCRIPT

The SCRIPT property parameter specifies the written script used in the property value which contains the parameter, which is amongst the valid codes in the ISO 15924 registry.

It is separated from the LANGUAGE property parameter defined in IETF RFC 5545 and IETF RFC 6350 for reasons stated in Clause 4.

Namespace
Property parameter name: SCRIPT
Purpose: To specify the script used in the property value, which is amongst the valid codes in the ISO 15924 registry.
Value type: TEXT, a single value valid in the ISO 15924 script registry.
Description: The property value of which this property parameter applies to must have identical structure to

5.1. vFormat Implementation of SCRIPT

Format definition

scriptparam = "SCRIPT" "=" script-code
            ; script-code defined in the value type SCRIPT-CODE

Figure 3

Examples

N;SCRIPT=Hira;LANGUAGE=jp:みやざき;はやお;;;
N;SCRIPT=Hani;LANGUAGE=jp:宮崎;駿;;;

Figure 4

6. Property Parameter: PHONETIC

A number of contact managers have long used “X-properties” to to store phonetic information of a vCard’s subject, such as X-PHONETIC-NAME, X-PHONETIC-FIRST-NAME and X-PHONETIC-LAST-NAME.

However, this is an issue for multiple reasons:

The value of the X-property does not define the phonetic system used for its transcription;
This X-property usage does not enable interoperability since it does not require specification of the language transcribed, as well as the script of the resulting transcription;
The scheme of using X-properties does not allow representation of phonetics on other vCard values.

This section defines three property parameters used to store pronunciation information of a property value:

The script used in the pronunciation system;
An identifier of the pronunciation system used;
The source language that was transcribed by the pronunciation system.

The PHONETIC property parameter specifies the phonetic system used in the transcription of the property value, identified by the phonetic system code from the ISO XXXXX phonetic system registry.

This property parameter is often applied together with the LANGUAGE (Clause 4) and SCRIPT (Clause 5) property parameters.

Namespace
Property parameter name: PHONETIC
Purpose: To specify the phonetic system used in the property value, which is amongst the valid codes in the ISO XXXXX registry.
Value type: TEXT, a single value valid in the ISO XXXXX phonetic system registry.
Description: The property value of which this property parameter applies to must take an identical structure to the property value without application of this property parameter.

6.1. vFormat Implementation of PHONETIC

Format definition

phoneticparam = "PHONETIC" "=" phonetic
phonetic      = 4ALPHA  ; ISO XXXXX 4-digit phonetic system code

Figure 5

Examples

N;SCRIPT=Hant;LANGUAGE=zho:孫;中山;文,逸仙;;
N;SCRIPT=Hans;LANGUAGE=zho:孙;中山;文,逸仙;;
N;PHONETIC=jyut;SCRIPT=Latn;LANGUAGE=yue:syun1;zung1saan1;man4,jat6sin1;;
N;PHONETIC=ping;SCRIPT=Latn;LANGUAGE=cmn:sun;zhongshan;rixian;;

Figure 6

7. Security Considerations

Security considerations of the vObject formats themselves MUST be adhered to, including:

vCard: IETF RFC 6350
iCalendar: IETF RFC 5545, IETF RFC 4791
vObject: Internet-Draft draft-calconnect-vobject-vformat-00

vObject formats, especially for calendaring, scheduling and contact exchange, often involve privacy-sensitive information. Internationalization features defined in this document MAY pose risk of exposing private information if interchanged through unprotected communication channels.

Mechanisms used for the transmission of such information should implement security measures to protect against possible threats, such as eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle attacks.

8. IANA Considerations

IANA is requested to register the following property parameters and value types in the corresponding iCalendar and vCard registries.

8.1. iCalendar and vCard Property Parameter Registration: SCRIPT

Namespace
Parameter name: SCRIPT
Purpose: Given in Clause 5.
Description: Given in Clause 5.
Format definition: Given in Clause 5.
Examples: Given in Clause 5.

8.2. iCalendar and vCard Property Parameter Registration: PHONETIC

Namespace
Parameter name: PHONETIC
Purpose: Given in Clause 6.
Description: Given in Clause 6.
Format definition: Given in Clause 6.
Examples: Given in Clause 6.

8.3. iCalendar and vCard Registration for Value Data Type: SCRIPT-CODE

Value name: SCRIPT-CODE
Purpose: Indicate script used in property value using a valid value from the ISO 15924 registry.
Description: Used by the SCRIPT property parameter.
Format definition

script-code = 4ALPHA
            ; ISO 15924 4-digit script code

Figure 7

Examples: Latn, Cyrl, Hani

8.4. iCalendar and vCard Registration for Value Data Type: PHONETIC-CODE

Value name: PHONETIC-CODE
Purpose: Indicate phonetic system used in the transcription of property value, using a valid value from the ISO XXXXX registry.
Description: Used by the SCRIPT property parameter.
Format definition

phonetic-code = 4ALPHA
              ; ISO XXXXX 4-digit script code

Figure 8

Examples: ipa, jyut, ping

Bibliography

[1] CalConnect TC VCARD, CalConnect VCARD Technical Committee

[2] CalConnect TC CALENDAR, CalConnect CALENDAR Technical Committee

[3] ISO 5127:2017, International Organization for Standardization (committee). Information and documentation — Foundation and vocabulary. Second edition. 2017. Geneva: International Organization for Standardization. https://www.iso.org/standard/59743.html.

[4] ISO 24624:2016, International Organization for Standardization (committee). Language resource management — Transcription of spoken language. First edition. 2016. Geneva: International Organization for Standardization. https://www.iso.org/standard/37338.html.

[5] IETF RFC 2119, BRADNER, S. Key words for use in RFCs to Indicate Requirement Levels. 1997. RFC Publisher. https://www.rfc-editor.org/info/rfc2119.

[6] IETF RFC 3986, BERNERS-LEE, T., R. FIELDING and L. MASINTER. Uniform Resource Identifier (URI): Generic Syntax. 2005. RFC Publisher. https://www.rfc-editor.org/info/rfc3986.

[7] IETF RFC 5646, Internet Engineering Task Force (committee). Tags for Identifying Languages. 2009. RFC Publisher. https://www.rfc-editor.org/info/rfc5646.

[8] IETF RFC 8174, LEIBA, B. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. 2017. RFC Publisher. https://www.rfc-editor.org/info/rfc8174.

[9] IETF RFC 6321, DABOO, C., M. DOUGLASS and S. LEES. xCal: The XML Format for iCalendar. 2011. RFC Publisher. https://www.rfc-editor.org/info/rfc6321.

[10] IETF RFC 7265, KEWISCH, P., C. DABOO, M. DOUGLASS and Internet Engineering Task Force. jCal: The JSON Format for iCalendar. 2014. RFC Publisher. https://www.rfc-editor.org/info/rfc7265.

[11] IETF RFC 7095, KEWISCH, P. and Internet Engineering Task Force. jCard: The JSON Format for vCard. 2014. RFC Publisher. https://www.rfc-editor.org/info/rfc7095.

[12] IETF RFC 6352, DABOO, C. and Internet Engineering Task Force. CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV). 2011. RFC Publisher. https://www.rfc-editor.org/info/rfc6352.

[13] IETF RFC 6351, PERREAULT, S. and Internet Engineering Task Force. xCard: vCard XML Representation. 2011. RFC Publisher. https://www.rfc-editor.org/info/rfc6351.

[14] IETF RFC 4791, DABOO, C., B. DESRUISSEAUX and L. DUSSEAULT. Calendaring Extensions to WebDAV (CalDAV). 2007. RFC Publisher. https://www.rfc-editor.org/info/rfc4791.

[15] IETF RFC 5234, OVERELL, P. Augmented BNF for Syntax Specifications: ABNF. 2008. RFC Publisher. https://www.rfc-editor.org/info/rfc5234.

[16] IETF RFC 8126, COTTON, M., B. LEIBA and T. NARTEN. Guidelines for Writing an IANA Considerations Section in RFCs. 2017. RFC Publisher. https://www.rfc-editor.org/info/rfc8126.