© 2019 The Calendaring and Scheduling Consortium, Inc.
This document is not a CalConnect Standard. It is distributed for review and comment, and is subject to change without notice and may not be referred to as a Standard. Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from the address below.
The Calendaring and Scheduling Consortium, Inc.
4390 Chaffin Lane
McKinleyville
California 95519
United States of America
www.calconnect.org
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.
vCard
These standards are used worldwide and require proper certain localization elements suitable for multi-cultural use.
Previously, the only internationalization method for vCard
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
This is a work product of the CalConnect TC-VCARD
Methods described in this document are intended to be used by vObject-compliant standards, such as vCard 4.0
For the purposes of this document, the following terms and definitions apply.
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
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
Notation in this document is described in ABNF
Definitions from
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.
For the purposes of this document, the following terms and definitions apply.
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
particular graphic representation or class of representations of a set of characters used to write one or more languages
representation or modelling of spoken language based on the sound system of the respective language
This section clarifies the intent of the LANGUAGE property parameter in
The
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
This document therefore clarifies the intent of
Other subtags MAY be supplied as specified in
LANGUAGE
To specify the language used in the property value.
LANGUAGE-TAG
As provided above.
The value of the LANGUAGE property parameter is re-defined as shown below.
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
SCRIPT
To specify the script used in the property value, which is amongst the valid codes in the ISO 15924 registry.
TEXT, a single value valid in the ISO 15924 script registry.
The property value of which this property parameter applies to must have identical structure to
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 (
PHONETIC
To specify the phonetic system used in the property value, which is amongst the valid codes in the ISO XXXXX registry.
TEXT, a single value valid in the ISO XXXXX phonetic system registry.
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.
Security considerations of the vObject formats themselves MUST be adhered to, including:
vCard:
iCalendar:
vObject:
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.
IANA is requested to register the following property parameters and value types in the corresponding iCalendar and vCard registries.
SCRIPT
Given in
Given in
Given in
Given in
PHONETIC
Given in
Given in
Given in
Given in
SCRIPT-CODE
Indicate script used in property value using a valid value from the ISO 15924 registry.
Used by the SCRIPT property parameter.
Latn, Cyrl, Hani
PHONETIC-CODE
Indicate phonetic system used in the transcription of property value, using a valid value from the ISO XXXXX registry.
Used by the SCRIPT property parameter.
ipa, jyut, ping
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.
This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. [STANDARDS-TRACK]
This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK]
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]
This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
This specification defines “xCal”, an XML format for iCalendar data. [STANDARDS-TRACK]
This specification defines “jCal”, a JSON format for iCalendar data. The iCalendar data format is a text format for capturing and exchanging information normally stored within a calendaring and scheduling application, for example, tasks and events. JSON is a lightweight, text-based, language-independent data interchange format commonly used in Internet applications.
This specification defines “jCard”, a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.
This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. [STANDARDS-TRACK]
This document defines the XML schema of the vCard data format. [STANDARDS-TRACK]
This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the “calendar-access” feature of CalDAV. [STANDARDS-TRACK]
Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]
Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).
To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.
This is the third edition of this document; it obsoletes RFC 5226.