Internet Engineering Task Force (IETF) R. Stepanek
Request for Comments: 9982 Fastmail
Updates: 9555 May 2026
Category: Standards Track
ISSN: 2070-1721
This document defines version "2.0" of JSContact. It defines the uid property of a Card object to be optional, rather than mandatory, as defined previously in version "1.0". All other definitions of JSContact version "1.0" remain as defined in RFC 9553. This document updates RFC 9555 by redefining how to convert the now optional uid property from and to vCard. It also registers the vCard JSCOMPS parameter at IANA, which was defined but not registered in RFC 9555.
この文書は、JSContact のバージョン「2.0」を定義します。これは、バージョン「1.0」で以前に定義されていたように、Card オブジェクトの uid プロパティを必須ではなくオプションとして定義します。JSContact バージョン "1.0" のその他すべての定義は、RFC 9553 での定義のままです。この文書は、現在オプションになっている uid プロパティを vCard との間で変換する方法を再定義することにより、RFC 9555 を更新します。また、RFC 9555 には定義されていましたが登録されていなかった vCard JSCOMPS パラメータも IANA に登録されます。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9982.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9982 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Notational Conventions
3. JSContact Version 2.0
4. Redefined uid Property
5. Redefined Conversion Rule for the uid Property
6. Other Changes
7. IANA Considerations
7.1. Update to the JSContact Version Registry
7.2. Update to the JSContact Properties Registry
7.3. Update to the vCard Parameters Registry
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Author's Address
JSContact [RFC9553] defines the Card object uid property, a mandatory property that contains a unique identifier for the entity represented by that contact card. For the same purpose, the vCard [RFC6350] contact format defines the UID property, an optional property of a vCard instance. Throughout the rest of this document, the term uid (all lowercase) denotes the JSContact uid property, and the term UID (all uppercase) denotes the vCard UID property.
JSContact [RFC9553] は、Card オブジェクトの uid プロパティを定義します。これは、その連絡先カードによって表されるエンティティの一意の識別子を含む必須プロパティです。同じ目的で、vCard [RFC6350] コンタクト形式は、vCard インスタンスのオプションのプロパティである UID プロパティを定義します。このドキュメントの残りの部分では、uid (すべて小文字) という用語は JSContact uid プロパティを示し、UID (すべて大文字) という用語は vCard UID プロパティを示します。
The uid property being defined as mandatory in JSContact has shown to be applicable for some use cases but turned out to be an issue in other contexts.
JSContact で必須として定義されている uid プロパティは、一部のユースケースには適用できることが示されていますが、他のコンテキストでは問題であることが判明しました。
1. A stated goal of JSContact is to be compatible with the semantics of the vCard data format (Section 1 of [RFC9553]). But [RFC6350] defines the UID property of a vCard to be optional, and consequently, the semantics of JSContact and vCard differ for such a crucial common element.
1. JSContact の目標は、vCard データ形式 ([RFC9553] のセクション 1) のセマンティクスと互換性があることです。しかし、[RFC6350] は vCard の UID プロパティをオプションであると定義しているため、このような重要な共通要素については JSContact と vCard のセマンティクスが異なります。
2. Address book synchronization protocols, such as CardDAV [RFC6352] and JMAP for Contacts [RFC9610], require the uid property. But other protocols, such as RDAP [RFC9083], have no use for it. JSContact should not require protocols to generate unique identifiers when they are irrelevant or even detrimental to the use case.
2. CardDAV [RFC6352] や JMAP for Contacts [RFC9610] などのアドレス帳同期プロトコルには、uid プロパティが必要です。しかし、RDAP [RFC9083] などの他のプロトコルではそれを使用できません。JSContact は、ユースケースに無関係な場合、またはユースケースに有害な場合さえある場合、プロトコルに一意の識別子の生成を要求すべきではありません。
3. Converting vCards having no UID property to JSContact is especially problematic: Section 2.1.1 of [RFC9555] requires implementations in this case to generate a unique identifier during conversion but does not require it to be the same across implementations or even one implementation converting the same Card multiple times. A recipient being unaware that the uid property value of such a Card object is ephemeral might refer to it in the members property or relatedTo property of another Card object, introducing invalid relations between contact cards.
3. UID プロパティを持たない vCard を JSContact に変換する場合は特に問題があります。[RFC9555] のセクション 2.1.1 では、この場合の実装は変換中に一意の識別子を生成する必要がありますが、実装間で同じである必要はなく、また、同じカードを複数回変換する 1 つの実装でさえも必要ありません。このような Card オブジェクトの uid プロパティ値が一時的なものであることに気づいていない受信者は、別の Card オブジェクトの members プロパティまたは requiredTo プロパティでその値を参照し、連絡先カード間に無効な関係が発生する可能性があります。
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
The ABNF definitions in this document use the notations of [RFC5234]. ABNF rules not defined in this document are defined in either [RFC5234] (such as the ABNF for CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT) or [RFC6350].
この文書の ABNF 定義では [RFC5234] の表記を使用します。この文書で定義されていない ABNF ルールは、[RFC5234] (CRLF、WSP、DQUOTE、VCHAR、ALPHA、および DIGIT の ABNF など) または [RFC6350] のいずれかで定義されます。
This document redefines the uid property of a Card object to become optional. Other than that, the property definition is left unchanged. This change requires the major version of JSContact to change, so this document defines the JSContact version to become "2.0". For further information about versioning JSContact data, see Section 1.9 of [RFC9553].
このドキュメントでは、Card オブジェクトの uid プロパティをオプションになるように再定義します。それ以外は、プロパティ定義は変更されません。この変更には JSContact のメジャー バージョンを変更する必要があるため、このドキュメントでは JSContact のバージョンが「2.0」になるように定義されています。JSContact データのバージョン管理の詳細については、[RFC9553] のセクション 1.9 を参照してください。
Implementations MUST create JSContact data that complies with the definitions of version "2.0" (or some later registered version) and MUST set the version property of the JSContact Card object to that version. They MUST NOT reject a Card object without the uid property as invalid unless specified differently in another document or unless the Card version property has value "1.0". As any valid version "1.0" JSContact Card is also valid according to version "2.0", there is no need to migrate existing JSContact data.
実装では、バージョン "2.0" (またはそれ以降に登録されたバージョン) の定義に準拠する JSContact データを作成しなければならず、JSContact Card オブジェクトの version プロパティをそのバージョンに設定しなければなりません。別のドキュメントで別途指定されている場合、または Card version プロパティの値が「1.0」でない限り、uid プロパティのない Card オブジェクトを無効として拒否してはなりません (MUST NOT)。有効なバージョン「1.0」の JSContact Card はバージョン「2.0」でも有効であるため、既存の JSContact データを移行する必要はありません。
This document does not redefine the vCard UID property.
このドキュメントでは、vCard UID プロパティを再定義しません。
This document redefines the type signature of the uid property, originally defined in Section 2.1.9 of [RFC9553].
この文書は、元々 [RFC9553] のセクション 2.1.9 で定義された uid プロパティの型シグネチャを再定義します。
OLD:
OLD:
*uid: String (mandatory).*
*uid: 文字列 (必須)。*
NEW:
NEW:
*uid: String (optional).*
*uid: 文字列 (オプション)。*
The remaining property definition is left unchanged, with the following additional paragraph:
残りのプロパティ定義は変更されず、次の段落が追加されます。
A Card without an uid property cannot be referred to as a group member in the members property (Section 2.1.6 of [RFC9553]) or put in relation to another Card object in the relatedTo property (Section 2.1.8 of [RFC9553]).
uid プロパティのない Card は、 members プロパティ ([RFC9553] のセクション 2.1.6) でグループ メンバーとして参照したり、relativeTo プロパティ ([RFC9553] のセクション 2.1.8) で別の Card オブジェクトとの関係に置くことはできません。
This document redefines how to convert the Card uid property from vCard, originally defined in Section 2.1.1 of [RFC9555]. The new conversion rule is as follows:
この文書は、元々 [RFC9555] のセクション 2.1.1 で定義された vCard から Card uid プロパティを変換する方法を再定義します。新しい変換ルールは次のとおりです。
Implementations that convert a vCard without a UID property (Section 6.7.6 of [RFC6350]) to a Card of version "2.0" or higher MUST NOT generate a unique identifier as a value for the uid property (Section 2.1.9 of [RFC9553]).
UID プロパティ ([RFC6350] のセクション 6.7.6) のない vCard をバージョン "2.0" 以降のカードに変換する実装では、uid プロパティ ([RFC9553] のセクション 2.1.9) の値として一意の識別子を生成してはなりません (MUST NOT)。
When converting a vCard without a UID property to JSContact version "1.0", implementations MUST generate a value for the uid property. How to generate unique identifiers is implementation-specific. Implementations SHOULD generate the same value when generating the same Card multiple times, but as Section 1 describes, this still cannot prevent interoperability issues. Consequently, implementations SHOULD NOT convert to version "1.0" Card objects.
UID プロパティのない vCard を JSContact バージョン "1.0" に変換する場合、実装は uid プロパティの値を生成しなければなりません (MUST)。一意の識別子の生成方法は実装によって異なります。実装では、同じカードを複数回生成するときに同じ値を生成する必要があります (SHOULD)。しかし、セクション 1 で説明したように、それでも相互運用性の問題を防ぐことはできません。したがって、実装はバージョン「1.0」の Card オブジェクトに変換すべきではありません。
This document also registers the JSCOMPS parameter in the IANA "vCard Parameters" registry. The parameter was defined in Section 3.3.1 of [RFC9555] but mistakenly not registered at IANA.
このドキュメントでは、JSCOMPS パラメータを IANA "vCard Parameters" レジストリに登録します。このパラメータは [RFC9555] のセクション 3.3.1 で定義されましたが、誤って IANA に登録されていませんでした。
IANA has updated the "JSContact Version" registry, originally created in Section 3.4 of [RFC9553], by adding the following record:
IANA は、最初に [RFC9553] のセクション 3.4 で作成された「JSContact Version」レジストリを、次のレコードを追加することで更新しました。
+===============+=======================+===========+
| Major Version | Highest Minor Version | Reference |
+===============+=======================+===========+
| 2 | 0 | RFC 9982 |
+---------------+-----------------------+-----------+
Table 1: JSContact Version Registry
表 1: JSContact バージョン レジストリ
IANA has updated the "JSContact Properties" registry, originally created in Section 3.5 of [RFC9553]: In the "Reference/Description" column of the uid property, a reference to Section 4 of this document has been added.
IANA は、元々 [RFC9553] のセクション 3.5 で作成された「JSContact Properties」レジストリを更新しました。uid プロパティの「参照/説明」列に、この文書のセクション 4 への参照が追加されました。
IANA has updated the "vCard Parameters" registry within the "vCard Elements" registry group by adding the following entry:
IANA は、次のエントリを追加することにより、「vCard Elements」レジストリ グループ内の「vCard Parameters」レジストリを更新しました。
+===========+===========+============================+
| Namespace | Parameter | Reference |
+===========+===========+============================+
| | JSCOMPS | Section 3.3.1 of [RFC9555] |
+-----------+-----------+----------------------------+
Table 2: vCard Parameters Registry
表 2: vCard パラメータ レジストリ
This document does not provide new security considerations. The security considerations of Section 4 of [RFC9553] apply.
この文書では、セキュリティに関する新たな考慮事項は提供しません。[RFC9553] のセクション 4 のセキュリティに関する考慮事項が適用されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
DOI 10.17487/RFC6350, August 2011,
<https://www.rfc-editor.org/info/rfc6350>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9553] Stepanek, R. and M. Loffredo, "JSContact: A JSON
Representation of Contact Data", RFC 9553,
DOI 10.17487/RFC9553, May 2024,
<https://www.rfc-editor.org/info/rfc9553>.
[RFC9555] Loffredo, M. and R. Stepanek, "JSContact: Converting from
and to vCard", RFC 9555, DOI 10.17487/RFC9555, May 2024,
<https://www.rfc-editor.org/info/rfc9555>.
[RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed
Authoring and Versioning (WebDAV)", RFC 6352,
DOI 10.17487/RFC6352, August 2011,
<https://www.rfc-editor.org/info/rfc6352>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>.
[RFC9610] Jenkins, N., Ed., "JSON Meta Application Protocol (JMAP)
for Contacts", RFC 9610, DOI 10.17487/RFC9610, December
2024, <https://www.rfc-editor.org/info/rfc9610>.
Robert Stepanek
Fastmail
PO Box 234
Collins St. West
Melbourne VIC 8007
Australia
Email: rsto@fastmailteam.com