Internet Engineering Task Force (IETF) C. Wendt
Request for Comments: 9796 Somos
Category: Standards Track J. Peterson
ISSN: 2070-1721 TransUnion
July 2025
SIP Call-Info Parameters for Rich Call Data
リッチコールデータのSIPコールINFOパラメーター
Abstract
概要
This document specifies a usage of the SIP Call-Info header field that incorporates Rich Call Data (RCD) associated with the identity of the originating party in order to provide to the terminating party a description of the caller (including details about the reason for the session). RCD includes information about the caller beyond the telephone number (such as a calling name, logo, photo, or jCard object representing the caller), which can help the called party decide how to handle the session request.
このドキュメントは、終了当事者に発信者の説明を提供するために、発信者のIDに関連付けられたリッチコールデータ（RCD）を組み込んだSIPコール-INFOヘッダーフィールドの使用法を指定します（セッションの理由の詳細を含む）。RCDには、電話番号を超えた発信者に関する情報（呼び出し名、ロゴ、写真、または発信者を表すJCardオブジェクトなど）が含まれています。
This document defines three new parameters 'call-reason', 'verified', and 'integrity' for the SIP Call-Info header field and also a new token ("jcard") for the 'purpose' parameter of the Call-Info header field. It also provides guidance on the use of the Call-Info 'purpose' parameter token, "icon".
このドキュメントでは、3つの新しいパラメーター「Call-Reason」、「Verified」、および「Integrity」をSIP Call-INFOヘッダーフィールドの「整合性」と、コールINFOヘッダーフィールドの「目的」パラメーターの新しいトークン（「JCard」）を定義します。また、Call-info '目的'パラメータートークン「Icon」の使用に関するガイダンスも提供します。
Status of This Memo
本文書の位置付け
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc9796.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9796で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Terminology
3. Overview
4. A Call-Info Framework for Carrying Rich Call Data
5. "jcard" Call-Info 'purpose' Token
6. 'call-reason' Call-Info Parameter
7. 'verified' Call-Info Parameter
8. 'integrity' Call-Info Parameter
9. Usage and an Example of Call-Info for RCD
10. Usage of jCard and Property-Specific Usage
10.1. Usage of URIs in jCard
10.2. Usage of Multimedia Data in jCard or with the "icon"
Call-Info 'purpose' Token
10.3. Cardinality
10.4. Identification Properties
10.4.1. "fn" Property
10.4.2. "n" Property
10.4.3. "nickname" Property
10.4.4. "photo" Property
10.5. Delivery Addressing Properties
10.5.1. "adr" Property
10.6. Communications Properties
10.6.1. "tel" Property
10.6.2. "email" Property
10.6.3. "lang" Property
10.7. Geographical Properties
10.7.1. "tz" Property
10.7.2. "geo" Property
10.8. Organizational Properties
10.8.1. "title" Property
10.8.2. "role" Property
10.8.3. "logo" Property
10.8.4. "org" Property
10.9. Explanatory Properties
10.9.1. "categories" Property
10.9.2. "note" Property
10.9.3. "sound" Property
10.9.4. "uid" Property
10.9.5. "url" Property
10.9.6. "version" Property
11. Extension of jCard
12. IANA Considerations
12.1. "jcard" Purpose Parameter Value
12.2. SIP Call-Info Header Field 'call-reason' Parameter
12.3. SIP Call-Info Header Field 'verified' Parameter
12.4. SIP Call-Info Header Field 'integrity' Parameter
13. Security Considerations
14. References
14.1. Normative References
14.2. Informative References
Acknowledgements
Authors' Addresses
Signaling protocols in telephone networks have long supported the delivery of a 'calling name' from the originating side to the terminating side; however, in practice, the terminating side is often left to derive a name from the calling-party number by consulting a local address book or an external database. SIP [RFC3261] similarly can carry a 'display-name' in the From header field value from the originating to terminating side, though it is a field that is not commonly trusted and is often replaced or ignored. The same can be considered true of information in the Call-Info header field in SIP.
電話ネットワークのシグナル伝達プロトコルは、元の側から終端側への「呼び出し名」の配信を長い間サポートしてきました。ただし、実際には、終了側は、地元のアドレス帳または外部データベースに相談することにより、呼び出しパーティ番号から名前を導き出すためにしばしば残されています。同様に、SIP [RFC3261]も同様に、ヘッダーフィールド値から発信元から終端側への「ディスプレイ名」を運ぶことができますが、一般的に信頼されておらず、しばしば交換または無視されるフィールドです。同じことは、SIPのCall-INFOヘッダーフィールドの情報に当てはまると見なすことができます。
This document defines usage of the SIP Call-Info header field [RFC3261] that allows called parties to receive a more comprehensive and extensible set of Rich Call Data (RCD) for incoming calls. It defines specific usage of the Call-Info header field, a new parameter ('call-reason'), and a new token ("jcard") for the 'purpose' parameter of the Call-Info header field. Depending on the policies of the communications system, a calling party could be either the end user device (e.g., a SIP user agent (UA)) or a network service as part of a telephone service provider. Similarly, a called party could be an end user device or the network telephone service provider acting on behalf of the recipient of the call.
このドキュメントでは、SIP Call-INFOヘッダーフィールド[RFC3261]の使用法を定義します。これにより、呼び出されたパーティーは、着信コールのためのより包括的で拡張可能なリッチコールデータ（RCD）を受け取ることができます。Call-INFOヘッダーフィールドの新しいパラメーター（「Call-Reason '）、およびCall-INFOヘッダーフィールドの「目的」パラメーターの新しいトークン（「JCard」）の特定の使用法を定義します。通信システムのポリシーに応じて、発信者はエンドユーザーデバイス（たとえば、SIPユーザーエージェント（UA））または電話サービスプロバイダーの一部としてのネットワークサービスのいずれかです。Similarly, a called party could be an end user device or the network telephone service provider acting on behalf of the recipient of the call.
In order to properly protect and communicate some of the authenticated and trusted properties of "rcd" claims defined in [RFC9795], this document defines two additional new parameters, 'verified' and 'integrity'. These parameters help protect RCD information that had been sent via a SIP network to, for example, a SIP entity on the edge of the Network-Network Interface (NNI) that contains a verification service as defined in [RFC8224] and further defined specific to RCD information in [RFC9795]. The verification procedures include the successful verification of the "rcd" claims and can be correspondingly represented in the Call-Info header field via these new parameters.
[RFC9795]で定義されている「RCD」クレームの認証された信頼できるプロパティの一部を適切に保護および伝達するために、このドキュメントは、「検証」と「完全性」という2つの追加の新しいパラメーターを定義します。これらのパラメーターは、SIPネットワークを介して送信されたRCD情報を、たとえば[RFC8224]で定義された検証サービスを含み、[RFC9795]のRCD情報に特異的に定義された検証サービスを含むSIPエンティティ（NNI）に保護するのに役立ちます。検証手順には、「RCD」クレームの成功した検証が含まれており、これらの新しいパラメーターを介してコールINFOヘッダーフィールドでそれに応じて表現できます。
Used on its own, this specification assumes that the called party UA can trust the SIP network to assign, deliver, and protect the correct RCD information as an end-to-end security policy. However, as is true in many interconnected communications services, this end-to-end trust cannot be guaranteed. Therefore, the recommended approach is that the entity inserting the Call-Info header field should also sign the caller information via protocol tools defined by Secure Telephone Identity Revisited (STIR) [RFC7340] for SIP [RFC8224] and specifically through the use of RCD or the "rcd" PASSporT defined in [RFC9795].
独自に使用されるこの仕様は、呼び出されたパーティーUAがSIPネットワークを信頼して、エンドツーエンドのセキュリティポリシーとして正しいRCD情報を割り当て、配信し、保護できることを前提としています。ただし、多くの相互接続された通信サービスで当てはまるように、このエンドツーエンドの信頼は保証することはできません。したがって、推奨されるアプローチは、Call-INFOヘッダーフィールドを挿入するエンティティが、SIP [RFC8224]の安全な電話のID（STIR）[RFC7340]、および[RFC9795]で定義された「RCD」パスポートの使用を通じて特異的に定義されたプロトコルツールを介して発信者情報に署名する必要があることです。
Alternatively, this specification can be utilized in conjunction with the protocols defined in [RFC9795] as part of the communications signaling path, specifically in the trusted User-Network Interface (UNI) device interface at the terminating side as part of an authenticated, network-to-device, trusted signaling where a device may not have the ability to verify the "rcd" PASSporT, but it can receive the RCD information from the Call-Info header field as defined in this specification.
あるいは、この仕様は、[RFC9795]で定義されたプロトコルと連携して、通信シグナリングパスの一部として、特に信頼できるユーザーネットワークインターフェイス（UNI）デバイスインターフェイスで、a dddの能力を提供する能力を検証する能力を把握する能力を持っている能力を持っている能力を持っている能力を持っている能力を持っている能力を持っている場合、デバイスを受け取る可能性のある信頼性のある信頼できるシグナルの一部として、終了側の終端側のデバイスインターフェイス（UNI）デバイスインターフェイスで、[RFC9795]で定義されたプロトコルと組み合わせて利用できます。この仕様で定義されているように、INFOヘッダーを呼び出します。
This specification provides an approach for the delivery of jCard data that utilizes the same mechanism as [RFC7852] which defined a means of carrying additional data about callers for the purposes of emergency services (especially Section 4.4 (Owner/Subscriber Information) of [RFC7852]). This document defines a 'purpose' parameter value "jcard" for the more generic delivery of information via jCard [RFC7095]. This document borrows from [RFC7852] the capability to carry a data structure as a body, through the use of the "cid" URI scheme [RFC2392].
この仕様は、[RFC7852]と同じメカニズム[RFC7852]と同じメカニズムを利用するJCARDデータの配信のアプローチを提供します。これは、緊急サービスの目的で発信者に関する追加データを運ぶ手段を定義しました（特に[RFC7852]のセクション4.4（所有者/加入者情報））。このドキュメントでは、JCard [RFC7095]を介した情報のより一般的な配信のために、「目的」パラメーター値「JCard」を定義します。このドキュメントは、[cid "URIスキーム[RFC2392]を使用して、[RFC7852]からデータ構造を身体として運ぶ機能を借りています。
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] で説明されているように解釈されます。
This document provides a framework for the use of Call-Info header field to carry RCD in SIP [RFC3261]. The Call-Info header field (defined in [RFC3261], Section 20.9) defines a 'purpose' parameter. In addition to providing guidance on calling name practices and the use of the existing 'purpose' parameter token, "icon", this document expands on other types of RCD by defining a new 'purpose' token, "jcard", and three new parameters, 'call-reason', 'verified', and 'integrity' for the Call-Info header field to align with RCD as defined in the STIR framework [RFC8224] and with "rcd" PASSporTs defined in [RFC9795].
このドキュメントは、SIP [RFC3261]でRCDを運ぶために、call-infoヘッダーフィールドを使用するためのフレームワークを提供します。Call-INFOヘッダーフィールド（[RFC3261]、セクション20.9で定義）は、「目的」パラメーターを定義しています。呼び出し名の練習と既存の「目的」パラメータートークン「アイコン」の使用に関するガイダンスを提供することに加えて、このドキュメントは、新しい「目的」トークン、「JCard」、および3つの新しいパラメーター、「コールリーズ」、「検証」、「検証」、および「Integrity」をasfo-info header frack as a a def in for and for and info infor fored for frace for frace for frace for frage for frage for frageで定義することにより、他のタイプのRCDを拡張します。[RFC9795]で定義された「RCD」パスポート。
The 'purpose' parameter token "jcard" is used to associate RCD related to the identity of the calling party in the form of a jCard [RFC7095]. While there is a "card" token defined in [RFC3261] which could be considered to have an overlapping purpose, the "jcard" token is intended to denote the jCard profile defined in this document for use in the Call-Info header field for RCD. The choice of jCard in this specification is guided by two aspects. jCard represents an extensible method of providing information about a person or business associated with a call, has been defined in [RFC9795], and has been adopted by PASSporT [RFC8225] because of the usage of JSON Web Tokens (JWT) [RFC7519].
「目的」パラメータートークン「JCARD」は、JCARD [RFC7095]の形で呼び出し当事者のIDに関連するRCDを関連付けるために使用されます。[RFC3261]で定義された「カード」トークンがありますが、これは重複する目的を持つと見なされますが、「JCard」トークンは、RCDのコールINFOヘッダーフィールドで使用するためにこのドキュメントで定義されているJCardプロファイルを示すことを目的としています。この仕様におけるJCardの選択は、2つの側面によって導かれます。JCardは、JSON Web Tokens（JWT）[RFC7519]の使用により、コールに関連する個人またはビジネスに関する情報を提供する拡張可能な方法を表し、[RFC9795]で定義されており、パスポート[RFC8225]で採用されています。
The new Call-Info header field parameter 'call-reason' conveys the caller's intent or reason for calling to help the called party understand the context and intent of the call and why they may want to answer the call.
新しいCall-INFO Headerフィールドパラメーター「Call-Reason」は、呼び出された当事者がコールのコンテキストと意図を理解するのを支援するために、発信者の意図または呼び出しの理由を伝えます。
The new Call-Info header field parameter 'verified' provides an indication, with the value "true", to represent the results of the verification procedures that were performed by the sender of the Call-Info header field. The new Call-Info header field parameter 'integrity' provides a mechanism to associate an integrity hash string, as defined in Section 8.2 of [RFC9795], that is associated with the content of the resource referenced by the URI represented in the Call-Info header field.
新しいCall-INFO Headerフィールドパラメーター「Verified」は、Call-INFOヘッダーフィールドの送信者によって実行された検証手順の結果を表すように、値「True」を備えた表示を提供します。新しいCall-INFOヘッダーフィールドパラメーター「Integrity」は、[RFC9795]のセクション8.2で定義されている整合性ハッシュ文字列を関連付けるメカニズムを提供します。
This specification extends the Call-Info header field to be compatible and complementary to the RCD framework defined in [RFC9795]. Typically, a SIP-based session involves multiple hops through different trusted and untrusted networks. The STIR framework [RFC7340] addresses the protection of the carriage of call information and identities over untrusted networks, which wasn't addressed in the core SIP specifications. [RFC3261], Section 20.9 defines the Call-Info header field as the mechanism for carrying call- and caller-related information and also provides procedures for defining new 'purpose' parameter tokens. This document discusses the use of existing tokens and defines a new 'purpose' token to correspond to the RCD framework.
この仕様は、[RFC9795]で定義されているRCDフレームワークに互換性があり補完的であるように、コールINFOヘッダーフィールドを拡張します。通常、SIPベースのセッションでは、信頼できる異なるネットワークを介した複数のホップが含まれます。Stir Framework [RFC7340]は、コアSIP仕様では対処されていない信頼されていないネットワーク上のコール情報とアイデンティティのキャリッジの保護に対処しています。[RFC3261]、セクション20.9では、コールINFOヘッダーフィールドをコールおよび発信者関連の情報を運ぶメカニズムとして定義し、新しい「目的」パラメータートークンを定義する手順も提供します。このドキュメントでは、既存のトークンの使用について説明し、RCDフレームワークに対応する新しい「目的」トークンを定義します。
There are a number of RCD information types that can be transmitted in the Call-Info header field of a SIP request. The STIR RCD specification [RFC9795] defines the following primary RCD elements: a calling name, a logo or icon associated with the caller, and a call reason string. It also discusses an extensible way to carry caller information using jCard [RFC7095].
SIPリクエストのCall-INFOヘッダーフィールドに送信できるRCD情報タイプが多数あります。Stir RCD仕様[RFC9795]は、次の主要なRCD要素を定義します。呼び出し名、発信者に関連付けられたロゴまたはアイコン、およびCall Reason Stringです。また、JCard [RFC7095]を使用して発信者情報を携帯する拡張可能な方法についても説明しています。
The RCD framework defined both in this document as well as in [RFC9795] carries call-specific information. The insertion of RCD is intended to be singular in that the receiving party should not be required to make any call-specific decisions based on redundant, duplicate, or conflicting RCD. The RCD information is either intended to be added by a party that is authoritative over that information or to have been translated from a verified STIR RCD PASSporT and unmodified once in a trusted domain. Any additional parties involved in the call path MUST NOT modify the Call-Info header field or add additional Call-Info header fields related to RCD. The trusted and verified caller RCD information inserted in the RCD Call-Info header field MUST NOT be modified or altered. The user should be able to trust that the RCD information accurately represents the verified information. This specification acknowledges that without the use of STIR or other mechanisms, detection of any modifications is not possible, so guidance for the use of this specification in a trusted UNI part of the network is important.
このドキュメントと[RFC9795]の両方で定義されたRCDフレームワークには、コール固有の情報が伝達されます。RCDの挿入は、冗長、重複、または矛盾するRCDに基づいて、受信当事者がコール固有の決定を下す必要はないという点で特異であることを目的としています。RCD情報は、その情報に対して権威ある当事者によって追加されることを目的としているか、検証済みの攪拌RCDパスポートから翻訳され、信頼できるドメインで1回変更されていないことを目的としています。コールパスに関与する追加の関係者は、コールINFOヘッダーフィールドを変更したり、RCDに関連するCall-INFOヘッダーフィールドを追加したりしてはなりません。RCD Call-INFOヘッダーフィールドに挿入された信頼できる検証済みの発信者RCD情報は、変更または変更してはなりません。ユーザーは、RCD情報が確認された情報を正確に表すことを信頼できる必要があります。この仕様は、攪拌や他のメカニズムを使用しないと、変更の検出が不可能であるため、ネットワークの信頼できる大学でこの仕様を使用するためのガイダンスが重要であることを認めています。
As discussed in [RFC9795], the calling name uses the display-name value of the From header field [RFC3261] of the request. Alternatively, for some calls, the calling name may come from the P-Asserted-ID header field [RFC3325]. While this is out of scope for the Call-Info header field in terms of the representation of the display-name value, this document does discuss the representation of the verification of this value using the 'verified' parameter.
[RFC9795]で説明したように、呼び出し名は、リクエストのFrom Headerフィールド[RFC3261]のディスプレイ名値を使用します。あるいは、一部の呼び出しの場合、呼び出し名はP-Asserted-IDヘッダーフィールド[RFC3325]から届く場合があります。これは、ディスプレイ名値の表現という観点からのコールINFOヘッダーフィールドの範囲外ですが、このドキュメントでは、「検証された」パラメーターを使用してこの値の検証の表現について説明します。
For logos or icons that can represent the calling party, the 'purpose' token "icon" [RFC3261] is used to indicate a URI for an image resource that can be displayed to the user receiving the SIP request. For the purpose of this document and the transmission of RCD, the "icon" 'purpose' token should be used as defined. Section 8.2 of [RFC9795] provides high-level guidance on image formatting and related information.
呼び出しパーティーを表すことができるロゴまたはアイコンの場合、「目的」トークン「アイコン」[RFC3261]を使用して、SIPリクエストを受信するユーザーに表示できる画像リソースのURIを示します。このドキュメントの目的とRCDの送信のために、「アイコン」目的のトークンを定義して使用する必要があります。[RFC9795]のセクション8.2は、画像のフォーマットと関連情報に関する高レベルのガイダンスを提供します。
This document defines 'call-reason' as a new parameter for the Call-Info header field. This parameter carries a string indicating the reason for the call.
このドキュメントでは、「コールリアンズ」をコールINFOヘッダーフィールドの新しいパラメーターと定義しています。このパラメーターには、呼び出しの理由を示す文字列が搭載されています。
jCard is a comprehensive and extensible mechanism utilized as part of the STIR RCD framework. While [RFC3261] specifies a "card" 'purpose' token, the intent of defining a new "jcard" 'purpose' token is to use the JSON jCard format [RFC7095] and to provide guidance for the use and non-use of jCard attributes to describe the calling party in a communications session as well to provide some security considerations around that information. These topics are covered in the next sections.
JCardは、Stir RCDフレームワークの一部として利用される包括的で拡張可能なメカニズムです。[RFC3261]は「カード」目的のトークンを指定しますが、新しい「JCard」目的 'トークンを定義する目的は、JSON JCard形式[RFC7095]を使用し、JCARD属性の使用と非使用のためのガイダンスを提供して、その情報に関するセキュリティに関するセキュリティセキュリティセッションを提供するための呼び出し党を説明することです。これらのトピックについては、次のセクションで説明します。
The Call-Info 'purpose' token "jcard" indicates support of RCD associated with the identity of a calling party in a SIP call [RFC3261], Section 20.9. The format of a Call-Info header field when using the "jcard" token is as follows.
Call-info '目的のトークン「JCard」は、SIPコール[RFC3261]、セクション20.9の呼び出しパーティーのIDに関連するRCDのサポートを示しています。「JCard」トークンを使用する場合のコールINFOヘッダーフィールドの形式は次のとおりです。
The Call-Info header field is defined to include a URI that points to a resource that is a jCard JSON object [RFC7095]. The media type for the JSON text MUST be set as application/json with an encoding of UTF-8 [RFC8259]. This MAY be carried directly in the Call-Info header field URI using the "data" URI scheme. A jCard also MAY be carried in the body of the SIP request bearing this Call-Info header field via the "cid" URI scheme [RFC2392]. Alternatively, the Call-Info header field URI MUST use a transport that can validate the integrity of the source of the resource (e.g., HTTPS tied to a specific validated domain). If, in the specific deployment environment of SIP, the source or integrity of the RCD information cannot be trusted, then the use of the STIR RCD framework defined in [RFC9795] should be considered.
Call-INFOヘッダーフィールドは、JCARD JSONオブジェクト[RFC7095]であるリソースを指すURIを含むように定義されています。JSONテキストのメディアタイプは、UTF-8 [RFC8259]のエンコードを使用して、アプリケーション/JSONとして設定する必要があります。これは、「データ」URIスキームを使用して、Call-INFOヘッダーフィールドURIに直接伝達される場合があります。JCardは、「CID」URIスキーム[RFC2392]を介して、このコールINFOヘッダーフィールドを含むSIPリクエストの本体にも運ばれる場合があります。あるいは、Call-INFOヘッダーフィールドURIは、リソースのソースの整合性を検証できるトランスポートを使用する必要があります（たとえば、特定の検証されたドメインに結び付けられたHTTPS）。SIPの特定の展開環境で、RCD情報のソースまたは整合性を信頼できない場合、[RFC9795]で定義されているSTIR RCDフレームワークの使用を考慮する必要があります。
Because the use and purpose of this specification is to provide a single presentation of RCD information, a call and its corresponding single RCD-related Call-Info header field MUST only contain a single jCard object represented by an array with two elements. The array MUST only include a single first element with the string "vcard", and the second element is an array of jCard properties corresponding to the single entity jCard object.
この仕様の使用と目的はRCD情報の単一のプレゼンテーションを提供することであるため、コールとその対応する単一のRCD関連のコールINFOヘッダーフィールドは、2つの要素を持つ配列で表される単一のJCardオブジェクトのみを含める必要があります。配列には、文字列「VCard」の単一の最初の要素のみを含める必要があり、2番目の要素は、単一のエンティティJCardオブジェクトに対応するJCardプロパティの配列です。
jCard has multiple fields that may convey similar information, for example, "fn", "n", or "nickname" are strings that represent names in different ways, or "photo" or "logo" represent a picture. Users of this specification should make sure there is consistency for the calling name string corresponding to the single name in the SIP From or P-Asserted-ID header field or a "logo" or "photo" corresponds to the RCD "icon" as described in the previous section. As described in [RFC8224] and [RFC9795] verification procedures, the values represented in the RCD MUST match the corresponding information in the SIP message to enable proper verification of calling name or icon consistently.
JCardには、「FN」、「N」、または「NickName」など、同様の情報を伝える可能性のある複数のフィールドがあります。これは、異なる方法で名前を表す文字列、または「写真」または「ロゴ」を表す文字列です。この仕様のユーザーは、前のセクションで説明したように、SIPまたは「ロゴ」または「写真」がRCD「アイコン」に対応するSIPまたは「ロゴ」または「写真」に対応する呼び出し名文字列の一貫性があることを確認する必要があります。[RFC8224]および[RFC9795]検証手順で説明されているように、RCDに表される値は、SIPメッセージの対応する情報と一致して、呼び出し名またはアイコンの適切な検証を一貫して有効にする必要があります。
An example of a Call-Info header field is:
コールINFOヘッダーフィールドの例は次のとおりです。
Call-Info: <https://example.com/qbranch.json>;purpose=jcard
An example of the contents of a URL-linked jCard JSON file is shown as follows:
URLリンクされたJCard JSONファイルの内容の例を次のように示します。
["vcard",
[
["version",{},"text","4.0"],
["fn",{},"text","Q Branch"],
["org",{},"text","MI6;Q Branch Spy Gadgets"],
["photo",{},"uri","https://example.com/photos/q-256x256.png"],
["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"],
["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"]
]
]
An example SIP INVITE using the "data" URI scheme is as follows:
「データ」URIスキームを使用したSIPの例は次のとおりです。
INVITE sip:alice@example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Alice <sip:alice@example.com>
From: Bob <sip:12155551000@example.com;user=phone>;tag=1928301774>
Call-ID: a84b4c76e66710
Call-Info: <data:application/json,["vcard",[["version",{},"text",
"4.0"],["fn",{},"text","Q Branch"],["org",{},"text","MI6;Q Branch
Spy Gadgets"],["photo",{},"uri","https://example.com/photos/quart
ermaster-256x256.png"],["logo",{},"uri","https://example.com/log
os/mi6-256x256.jpg"],["logo",{},"uri","https://example.com/logos/
mi6-64x64.jpg"]]]\>;purpose=jcard;call-reason="Rendezvous for
Little Nellie"
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Fri, 25 Sep 2025 19:12:25 GMT
Contact: <sip:12155551000@gateway.example.com>
Content-Type: application/sdp
v=0 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com s=Session SDP c=IN IP4 pc33.atlanta.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
V = 0 O = USERA 2890844526 2890844526 IN IP4 PC33.ATLANTA.EXAMPLE.COM S =セッションSDP C = IN IP4 PC33.ATLANTA.EXAMPLE.COM T = 0 0 M = Audio 49172 RTP/AVP 0 A = RTPMAP：0 PCMU/8000
An example SIP INVITE using the "cid" URI scheme is as follows:
「CID」URIスキームを使用したSIPの例は次のとおりです。
INVITE sip:alice@example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Alice <sip:alice@example.com>
From: Bob <sip:12155551000@example.com;user=phone>;tag=1928301774>
Call-ID: a84b4c76e66710
Call-Info: <cid:12155551000@example.com>;purpose=jcard;
call-reason="Rendezvous for Little Nellie"
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Fri, 25 Sep 2025 19:12:25 GMT
Contact: <sip:12155551000@gateway.example.com>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
-boundary1
Content-Type: application/sdp
v=0 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com s=Session SDP c=IN IP4 pc33.atlanta.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
V = 0 O = USERA 2890844526 2890844526 IN IP4 PC33.ATLANTA.EXAMPLE.COM S =セッションSDP C = IN IP4 PC33.ATLANTA.EXAMPLE.COM T = 0 0 M = Audio 49172 RTP/AVP 0 A = RTPMAP：0 PCMU/8000
--boundary1
-boundary1
Content-Type: application/json
Content-ID: <12155551000@example.com>
["vcard",[["version",{},"text","4.0"],["fn",{},"text","Q Branch"],
["org",{},"text","MI6;Q Branch Spy Gadgets"],["photo",{},"uri","
https://example.com/photos/quartermaster-256x256.png"],["logo",
{},"uri","https://example.com/logos/mi6-256x256.jpg"],["logo",{},
"uri","https://example.com/logos/mi6-64x64.jpg"]]]
This parameter is intended to be separate and distinct from the other URI and 'purpose' tokens that may precede these parameters.
このパラメーターは、これらのパラメーターに先行する可能性のある他のURIおよび「目的」トークンとは分離され、異なることを目的としています。
This new parameter of the Call-Info header field is called 'call-reason'. The 'call-reason' parameter is intended to convey a short textual message suitable for display to an end user during call alerting. As a general guideline, this message SHOULD be no longer than 64 characters; displays that support this specification may be forced to truncate messages that cannot fit onto a screen. This message conveys the caller's intention in contacting the callee. It is an optional parameter, and the sender of a SIP request cannot guarantee that its display will be supported by the terminating endpoint. The manner in which this reason is set by the caller is outside the scope of this specification. In general, use of strings that could be forms of URIs or other potential strings that could be used or interpreted as a 'clickable' action is discouraged.
Call-INFOヘッダーフィールドのこの新しいパラメーターは、「Call-Reason」と呼ばれます。「Call-Reason」パラメーターは、Call Alerting中にエンドユーザーに表示に適した短いテキストメッセージを伝えることを目的としています。一般的なガイドラインとして、このメッセージは64文字以下でなければなりません。この仕様をサポートするディスプレイは、画面に収まらないメッセージを切り捨てることを余儀なくされる場合があります。このメッセージは、Calleeに連絡する際の発信者の意図を伝えます。これはオプションのパラメーターであり、SIPリクエストの送信者は、そのディスプレイが終端エンドポイントによってサポートされることを保証することはできません。この理由が発信者によって設定される方法は、この仕様の範囲外です。一般に、「クリック可能な」アクションとして使用または解釈できるURIまたはその他の潜在的な文字列である可能性のある文字列の使用は落胆します。
An alternative approach would have been to use the value of Subject header field [RFC3261] to convey the reason for the call. However, because the Subject header field has seen little historical use in SIP implementations and its specification describes its potential use in filtering, it seemed prudent to define a new means of carrying a call-reason indication.
代替アプローチは、サブジェクトヘッダーフィールド[RFC3261]の値を使用して、コールの理由を伝えることでした。ただし、サブジェクトヘッダーフィールドはSIP実装で歴史的使用がほとんど見られず、その仕様はフィルタリングにおけるその潜在的な使用を説明しているため、コールリーズシーズンの兆候を運ぶ新しい手段を定義することは賢明なようでした。
An example of a Call-Info header field value with the "call-reason" parameter follows:
「コールリアン」パラメーターを使用したコールINFOヘッダーフィールド値の例は次のとおりです。
Call-Info: <https://example.com/jbond.json>;purpose=jcard;
call-reason="For your ears only"
For 'call-reason' or 'verified' parameters defined in this document that do not require an associated URI or for future parameters that do not require an associated URI, the Call-Info header field URI should be set to the null data URI, "data:". The purpose parameter "jcard", defined in this document, is used to avoid any conflicts or confusion with existing implementations and previously defined purpose parameters. As an example:
関連するURIまたは関連するURIを必要としない将来のパラメーターについては、このドキュメントで定義されている「コールリアン」または「検証された」パラメーターの場合、コールINFOヘッダーフィールドURIは、null data uri、 "data："に設定する必要があります。このドキュメントで定義されている目的パラメーター「JCard」は、既存の実装や以前に定義された目的パラメーターとの競合や混乱を回避するために使用されます。例として：
Call-Info: <data:>;purpose=jcard;
call-reason="For your ears only"
The 'verified' parameter extends and complements the content conveyed by the RCD-related Call-Info header field. This parameter indicates to the recipient that the information contained in the Call-Info header field has been verified by verification procedures for claims defined in Section 8 of [RFC9795]. The presence of a 'verified' parameter on a Call-Info header field should be considered specific to the information for that Call-Info header field only. If there is a Call-Info header field corresponding to information defined in this specification that doesn't contain a 'verified' parameter, the recipient should assume that information was not received and verified corresponding to the verification procedures defined in Section 8 of [RFC9795].
「検証された」パラメーターは、RCD関連のコールINFOヘッダーフィールドによって伝えられるコンテンツを拡張および補完します。このパラメーターは、[RFC9795]のセクション8で定義されているクレームの検証手順によって、コール-INFOヘッダーフィールドに含まれる情報が検証されていることを受信者に示します。Call-INFOヘッダーフィールドに「検証された」パラメーターの存在は、そのコールINFOヘッダーフィールドのみの情報に固有のものと見なす必要があります。「検証された」パラメーターを含まないこの仕様で定義されている情報に対応するコールINFOヘッダーフィールドがある場合、受信者は、[RFC9795]のセクション8で定義されている検証手順に対応する情報が受信および検証されていないと仮定する必要があります。
There is a single valid value associated with the 'verified' parameter of 'true'. The value 'true' indicates to the recipient that the party that included the Call-Info header field performed a successful verification of the information represented. As a general principle of Call-Info header field information, the recipients' ability to trust the 'verified' parameter is based on the trusted relationship with the party from whom they are receiving the SIP request.
「true」の「検証された」パラメーターに関連付けられた単一の有効な値があります。値「真」は、Call-INFOヘッダーフィールドを含む当事者が、表明された情報の検証を成功させたことを受信者に示します。Call-INFOヘッダーフィールド情報の一般原則として、「検証済み」パラメーターを信頼する受信者の能力は、SIPリクエストを受けている当事者との信頼できる関係に基づいています。
The following is an example where the parameter verified="true" is used to represent that a verification procedure has been performed within a trusted domain to indicate the "icon" URL has been successfully verified:
以下は、パラメーター検証= "true"を使用して、信頼できるドメイン内で検証手順が実行され、「アイコン」URLが正常に検証されていることを示す例です。
Call-Info: <https://example.com/jbond.png>;purpose=icon;
verified="true"
In addition to the use of the indication of successful verification of RCD information, an important usage of the 'verified' parameter is to indicate verification of display-name information, sometimes referred to as calling name or CNAM.
RCD情報の検証が成功したことを示していることに加えて、「検証された」パラメーターの重要な使用法は、呼び出し名またはCNAMと呼ばれるディスプレイ名情報の検証を示すことです。
In the following example, a call was delivered via an NNI to a terminating provider with the following STIR RCD PASSporT.
次の例では、次のStir RCDパスポートを使用して、NNIを介して終了プロバイダーに通話が配信されました。
Protected Header
{
"alg":"ES256",
"typ":"passport",
"ppt":"rcd",
"x5u":"https://cert.example.org/passport.pem"
}
Payload
{
"dest":{"tn":["12025551001"]},
"iat":1443208345,
"orig":{"tn":"12025551000"},
"rcd":{"nam":"James Bond","icn":"https://example.com/jbond.png"}
}
The terminating provider receives a SIP INVITE with an identity header containing the STIR RCD PASSporT that is verified through a verification service. The provider then wants to deliver the call to an end device in the trusted and authenticated UNI network. The provider uses local policies to determine the information to present to the end device. The following example SIP INVITE could be used to represent the RCD information using two Call-Info header fields. Because both the icon and calling name have passed verification, a Call-Info header for the "icon" is added with a verified="true" parameter, and the use of Call-Info with a null data URI is used, as discussed in the "call-reason" section above. This document defines that the display-name information in either the From and/or P-Asserted-ID header field has been verified via RCD PASSporT verification procedures when the following is present: a 'purpose' parameter tokens of "jcard", a Call-Info header field with a null data URI "data:", and a verified parameter equal to "true".
終了プロバイダーは、検証サービスを通じて検証されたStir RCDパスポートを含むIDヘッダーを備えたSIP招待状を受け取ります。プロバイダーは、信頼できる認証されたUNIネットワークのエンドデバイスに呼び出しを配信したいと考えています。プロバイダーは、ローカルポリシーを使用して、最終デバイスに提示する情報を決定します。次の例SIP Inviteを使用して、2つのCall-INFOヘッダーフィールドを使用してRCD情報を表すことができます。アイコンと呼び出し名の両方が検証に合格しているため、「アイコン」の呼び出しINFOヘッダーが検証=「真」パラメーターで追加され、上記の「コールリーズ」セクションで説明されているように、nullデータURIを使用したコール-INFOの使用が使用されます。このドキュメントでは、次のように存在する場合、fromおよび/またはp-asserted-idヘッダーフィールドのディスプレイ名情報がRCDパスポート検証手順を介して検証されていることを定義しています。「jcard」の「目的」パラメータートークン、null data uri "uri" data： ""：trueに等しく等しいnull data uri "uri" data "null data uri" data "data"の「jcard」。
Example SIP INVITE described above:
上記のSIP招待状の例：
INVITE sip:qbranch@example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: "QBranch" <sip:qbranch@example.com>
From: "James Bond" <sip:12155551000@example.com;user=phone>;
tag=1928>
Call-ID: a84b4c76e66710
Call-Info: <https://example.com/jbond.png>;purpose=icon;
verified="true"
Call-Info: <data:>;purpose=jcard;verified="true"
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Fri, 25 Sep 2025 19:12:25 GMT
Contact: <sip:12155551000@gateway.example.com>
Content-Type: application/sdp
v=0 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com s=Session SDP c=IN IP4 pc33.atlanta.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
V = 0 O = USERA 2890844526 2890844526 IN IP4 PC33.ATLANTA.EXAMPLE.COM S =セッションSDP C = IN IP4 PC33.ATLANTA.EXAMPLE.COM T = 0 0 M = Audio 49172 RTP/AVP 0 A = RTPMAP：0 PCMU/8000
The 'integrity' parameter extends and complements the integrity information conveyed specifically by the "rcdi" claim in the RCD-related Call-Info header field. This parameter is used to indicate, for a URI represented in the Call-Info header field, that the resource referenced by that URI has an associated integrity hash value, based conceptually on [W3C-SRI]. Section 6 of [RFC9795] describes the procedures for the creation of the digest value including the hash algorithm indicator a '-' separator and the hash value as a string. The JSON pointer object container described as the container of the 'rcdi' hashes is not necessary because each hash value should only correspond to a single URI. Corresponding to guidance defined in Section 6 of [RFC9795], implementations of this specification MUST support the hash algorithms SHA-256, SHA-384, and SHA-512. These hash algorithms are identified by "sha256", "sha384", and "sha512", respectively.
「整合性」パラメーターは、RCD関連のCall-INFOヘッダーフィールドの「RCDI」クレームによって具体的に伝えられる整合性情報を拡張および補完します。このパラメーターは、コールINFOヘッダーフィールドに表されるURIについて、そのURIが参照されるリソースが[W3C-SRI]に基づいて関連する整合性ハッシュ値を持っていることを示すために使用されます。[RFC9795]のセクション6では、ハッシュアルゴリズムインジケーターa ' - 'セパレーターとハッシュ値を含むハッシュアルゴリズム値を含むダイジェスト値の作成手順について説明します。各ハッシュ値は単一のURIにのみ対応する必要があるため、「RCDI」ハッシュの容器として記述されたJSONポインターオブジェクトコンテナは必要ありません。[RFC9795]のセクション6で定義されているガイダンスに対応して、この仕様の実装は、ハッシュアルゴリズムSHA-256、SHA-384、およびSHA-512をサポートする必要があります。これらのハッシュアルゴリズムは、それぞれ「SHA256」、「SHA384」、および「SHA512」によって識別されます。
Assuming the URI and the resource pointing to the URI don't change between the STIR RCD PASSporT and the Call- Info URI value, the integrity value can typically be used as the same corresponding string in both the "rcdi" claim and the 'integrity' parameter.
URIとURIを指すリソースがStir RCDパスポートとコール情報URI値の間で変化しないと仮定すると、整合性値は通常、「RCDI」クレームと「整合性」パラメーターの両方で同じ対応する文字列として使用できます。
Note: When the 'rcdi' claim is part of the successfully verified RCD PASSporT, the Call-Info Header Field should include both the 'verified' and 'integrity' parameters. Creation of a Call-Info header field based on an identity header field that carries RCD claims that does not pass verification procedures is not suggested (i.e., the inclusion of an 'integrity' parameter without a properly included 'verified' parameter).
注：「RCDI」クレームが正常に検証されたRCDパスポートの一部である場合、Call-INFOヘッダーフィールドには「検証済み」パラメーターと「整合性」パラメーターの両方を含める必要があります。検証手順に合格しないRCDクレームを運ぶアイデンティティヘッダーフィールドに基づいたコールINFOヘッダーフィールドの作成
Example STIR RCD PASSporT:
例RCDパスポートを攪拌する：
Protected Header
{
"alg":"ES256",
"typ":"passport",
"ppt":"rcd",
"x5u":"https://cert.example.org/passport.pem"
}
Payload
{
"crn": "Rendezvous for Little Nellie",
"dest": {"tn": ["12155551001"]},
"iat": 1443208345,
"orig": {"tn": "12025551000"},
"rcd": {
"nam": "Q Branch Spy Gadgets",
"icn": "https://example.com/photos/q-256x256.png"
},
"rcdi": {
"/icn": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4"
}
}
Example corresponding SIP INVITE with Call-Info information derived from RCD information above:
上記のRCD情報から派生したCALL-INFO情報に対応するSIPの例：
INVITE sip:qbranch@example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: "James Bond" <sip:12155551001@example.com;user=phone>
From: "Q Branch Spy Gadgets" <sip:12025551000@example.com;
user=phone>;tag=1928>
Call-ID: a84b4c76e66710
Call-Info: <https://example.com/photos/q-256x256.png>;purpose=
icon;verified="true";integrity="sha256-RojgWwU6xUtI4q82+kHPyHm
1JKbm7+663bMvzymhkl4"
Call-Info: <data:>;purpose=jcard;call-reason="Rendezvous for
Little Nellie";verified="true"
Call-Info: <data:>;purpose=jcard;verified="true"
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Fri, 25 Sep 2025 19:12:25 GMT
Contact: <sip:12155551000@gateway.example.com>
Content-Type: application/sdp
v=0 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com s=Session SDP c=IN IP4 pc33.atlanta.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
V = 0 O = USERA 2890844526 2890844526 IN IP4 PC33.ATLANTA.EXAMPLE.COM S =セッションSDP C = IN IP4 PC33.ATLANTA.EXAMPLE.COM T = 0 0 M = Audio 49172 RTP/AVP 0 A = RTPMAP：0 PCMU/8000
The procedures for the usage of URIs and 'purpose' parameter tokens should follow the procedures defined in [RFC3261]. The general management and provisioning of RCD for an initiating party requires a lot of validation of information regarding that specific initiating party, which is out of scope of this document. Since the 'rcd' Call-Info header field is verified during the transition from the Network-to-Network Interface (NNI) to the User-to-Network Interface (UNI), a common approach is to extract and translate the verified information from a received STIR 'rcd' PASSporT into this header field. This allows the RCD to be delivered to the end user device through the UNI.
URISおよび「目的」パラメータートークンの使用手順は、[RFC3261]で定義されている手順に従う必要があります。開始党のRCDの一般的な管理とプロビジョニングには、この文書の範囲外である特定の開始党に関する情報の多くの検証が必要です。「RCD」コールINFOヘッダーフィールドは、ネットワーク間インターフェイス（NNI）からユーザー間インターフェイス（UNI）への移行中に検証されるため、一般的なアプローチは、受信された攪拌 'RCD'パスポートから確認された情報をこのヘッダーフィールドに抽出して変換することです。これにより、RCDをUNIを介してエンドユーザーデバイスに配信できます。
The following example provides both the STIR RCD PASSporT and the corresponding set of Call-Info header fields showing the use of multiple Call-Info 'purpose' tokens to indicate "jCard" and "icon" and also a 'call-reason' Call-Info parameter:
次の例は、sir rcdパスポートと、「jcard」と「アイコン」を示すための複数のコールインフォ '目的'トークンの使用を示す対応するコール-infoヘッダーフィールドの両方を提供します。
Example STIR RCD PASSporT:
例RCDパスポートを攪拌する：
Protected Header
{
"alg":"ES256",
"typ":"passport",
"ppt":"rcd",
"x5u":"https://cert.example.org/passport.pem"
}
Payload
{
"crn":"For your ears only",
"dest":{"tn":["12025551001"]},
"iat":1443208345,
"orig":{"tn":"12025551000"},
"rcd":{
"jcl":"https://example.com/qbranch.json",
"icn":"https://example.com/jbond.png"
},
"rcdi": {
"/jcl": "sha256-yHm1JKbm7+663bMvzymhkl4RojgWwU6xUtI4q82+kHP"
"/icn": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4"
}
}
Example Call-Info header fields:
例Call-INFOヘッダーフィールド：
Call-Info: <data:>;purpose=jcard;verified="true"
Call-Info: <https://example.com/jbond.json>;purpose=jcard;verified
=true;integrity="sha256-yHm1JKbm7+663bMvzymhkl4RojgWwU6xUtI4q82
+kHP"
Call-Info: <https://example.com/jbond.png>;purpose=icon;
call-reason="For your ears only";verified=true;integrity=
"sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4"
Beyond the definition of the specific properties or JSON arrays associated with each property, this specification defines a few rules beyond those defined in [RFC7095] that are specific to the use of jCard for Call-Info and RCD to ensure there is a minimum level of supported properties to which every implementation of this specification should adhere. This includes support for interpreting the value of these properties and the ability to render in some appropriate form the display capabilities of common telephone devices as well as applications, and also includes requirements specific to textual and graphics-capable displays.
各プロパティに関連付けられている特定のプロパティまたはJSONアレイの定義を超えて、この仕様は、[RFC7095]で定義されたものを超えたいくつかのルールを定義します。これは、コールINFOおよびRCDにJCARDを使用して、この仕様のすべての実装が順守すべきサポートされたプロパティの最小レベルがあることを確認します。これには、これらのプロパティの価値を解釈するためのサポートと、適切な形式で一般的な電話デバイスの表示機能とアプリケーションをレンダリングする能力が含まれ、テキストおよびグラフィックセイプ可能なディスプレイに固有の要件も含まれます。
When one or more URIs are used in a jCard, it is important to note that any URI-referenced data, with the exception of the top-level usage of "jcl" as a URI to the jCard itself MUST NOT contain any URI references. In other words, the jCard can have URI references as defined in the jCard specification and this document, but the content referenced by those URIs MUST NOT have any URIs; therefore, the client MUST ensure that those URI references are not followed, and any URIs that are present in that specific URI-linked content are not rendered. The purpose of this is to control the security and more specifically to align with the content-integrity mechanism defined in [RFC9795]. There is not anticipated to be need for which deeper URI references would be required or even supported by the typical use of current jCard properties. However, because jCard is extensible, this rule is set to restrict further extension without the proper consideration of security and integrity properties of both Call-Info usage as well as the RCD and STIR signing of the data [RFC9795] [RFC8224].
JCARDで1つ以上のURIが使用される場合、JCARD自体のURIとしての「JCL」のトップレベルの使用を除き、URI参照データを除いて、URI参照データを除き、URI参照データを含めてはならないことに注意することが重要です。言い換えれば、JCardにはJCard仕様とこのドキュメントで定義されているURI参照を持つことができますが、それらのURIが参照するコンテンツにはurisが必要です。したがって、クライアントは、これらのURI参照が従わないことを確認する必要があり、その特定のURI結合コンテンツに存在するURIはレンダリングされません。これの目的は、セキュリティを制御することであり、より具体的には[RFC9795]で定義されているコンテンツ統合メカニズムに合わせることです。現在のJCardプロパティの典型的な使用によって、より深いURI参照が必要であるか、さらにはサポートされる必要があるとは予想されていません。ただし、JCARDは拡張可能であるため、このルールは、コールINFO使用法のセキュリティと整合性のプロパティを適切に考慮せずに、RCDとデータの攪拌署名[RFC9795] [RFC8224]の両方を制限するように設定されています。
10.2. Usage of Multimedia Data in jCard or with the "icon" Call-Info 'purpose' Token
10.2. JCardまたは「アイコン」コールインフォ '目的'トークンでのマルチメディアデータの使用
For the use of the 'purpose' token "icon" or for the cases where the jCard either incorporates URIs or includes digital images and sounds directly via Base64 encoding (Section 4 of [RFC4648]), this document provides guidance at the time of writing that can be adopted to facilitate the successful decoding and rendering of these images and media formats. Note that media formats are likely something implementers need to consider for their specific application.
「目的」トークン「アイコン」を使用するか、JCardがURIを組み込んでいるか、Base64エンコーディングを介してデジタル画像とサウンドを直接含める場合（[RFC4648]のセクション4）、このドキュメントは、これらの画像とメディア形式のデコードとレンダリングの成功を促進するために採用できる執筆時にガイダンスを提供します。メディア形式は、実装者が特定のアプリケーションについて考慮する必要があるものである可能性が高いことに注意してください。
For images, such as for the "photo" and "logo" properties, the default image formats SHOULD be PNG [ISOPNG] or JPEG [ITUJPEG], as these files are commonly used to support 24-bit RGB images. Supporting older telephone devices that only support bitmap (BMP) images [RFC7903] with a lower bit range (e.g., 16-bit, 8-bit, or 1-bit), or grayscale, or 1-bit black and white color displays, should be considered optional or even not recommended because, at the time of writing, they are becoming increasingly rare (i.e., typically, devices either have color or color-aware graphical displays that support PNG or JPEG formats or they are exclusively textual displays).
「写真」や「ロゴ」プロパティなどの画像の場合、デフォルトの画像形式は、24ビットRGB画像をサポートするために一般的に使用されるため、PNG [ISOPNG]またはJPEG [itujpeg]である必要があります。ビットマップ（BMP）画像[RFC7903]のみをサポートする古い電話デバイスをサポートする（例：16ビット、8ビット、または1ビット）、またはグレースケール、または1ビットの黒と白のディスプレイでは、執筆時には、執筆時には希少になるため、典型的には希少なものであるため、執筆時には、筆記されていないため、オプションまたは推奨されないと見なされるべきであると考えられます。PNGまたはJPEG形式またはそれらは、テキストのみのディスプレイです）。
In addition, vector images are increasingly popular to use as icons because they support scalable images without having to send multiple resolutions. The SVG format has gained wide support as of this writing as a common format for vector images. At a minimum, the SVG Tiny 1.2 specification [W3C-SVGTiny1.2] SHOULD be supported as an additional default format for devices.
さらに、複数の解像度を送信することなくスケーラブルな画像をサポートするため、ベクター画像はアイコンとして使用することがますます一般的になっています。SVG形式は、ベクトル画像の共通形式として、この執筆時点で幅広いサポートを得ています。少なくとも、SVG Tiny 1.2仕様[W3C-SVGTINY1.2]は、デバイスの追加のデフォルト形式としてサポートする必要があります。
For the cases where image files are referenced by URIs as file resources, this document defines a character string that SHOULD be concatenated onto the end of a file name, but before the file extension, that signals the height and width of the image to the end device for the convenience of determining the appropriate resolution to retrieve files without the need to retrieve all the image files. It is also recommended that images have a square aspect ratio with equal height and width and with a power-of-two value for the number of pixels (e.g., 32x32, 128x128, 512x512). The format of the string should be "filename-HxW", where "filename" is a unique string representing the file, "H" represents the height in pixels, and "W" represents the width in pixels.
画像ファイルがurisによってファイルリソースとして参照される場合、このドキュメントは、ファイル名の最後に連結する必要がある文字文字列を定義しますが、ファイル拡張子の前に、すべての画像ファイルを取得する必要なく適切な解像度を決定するために適切な解像度を決定するために、画像の高さと幅を最終デバイスに指示します。また、画像には、高さと幅が等しく、ピクセル数（32x32、128x128、512x512など）の2つの値を持つ正方形のアスペクト比を持つことをお勧めします。文字列の形式は「Filename-hxw」でなければなりません。ここで、「filename」はファイルを表す一意の文字列であり、「h」はピクセルの高さを表し、「w」はピクセルの幅を表します。
It is appropriate and useful to include multiple versions of images or sounds so that endpoints that cannot support all formats or resolutions can select the format they do support. The RECOMMENDED convention is for files that refer to the same content to use the same filename portion. If the image format has a specific resolution, the HxW portion of the filename should correspond to the pixel resolution. The file extension should reference the file type (e.g., filename.png, filename.svg, or filename.jpg) or (e.g., filename-32x32.png, filename-64x64.png, filename.svg, filename-32x32.jpg, or filename-64x64.jpg).
複数のバージョンの画像またはサウンドを含めることが適切かつ便利で、すべての形式や解像度をサポートできないエンドポイントが、サポートする形式を選択できるようにします。推奨される規則は、同じコンテンツを参照して同じファイル名部分を使用するファイル用です。画像形式に特定の解像度がある場合、ファイル名のHXW部分はピクセル解像度に対応する必要があります。ファイル拡張子は、ファイルの種類（filename.png、filename.svg、またはfilename.jpgなど）または（例えば、filename-32x32.png、filename-64x64.png、filename.svg、filename-32x32.jpgまたはfilename-64x64.jpg.jpg.jpg）を参照する必要があります。
Because this is a complex and often debated topic that has evolved over the many years of advances in image coding and display technologies, this specification suggests relying on either future specifications or industry forum specifications that might correspond to supporting particular classes of devices to further define how URIs can reference appropriate image formats and files.
これは、画像コーディングとディスプレイテクノロジーの長年にわたって進化してきた複雑でしばしば議論されるトピックであるため、この仕様は、将来の仕様または業界フォーラム仕様のいずれかに依存して、特定のクラスのデバイスをサポートして適切な画像形式とファイルを参照する方法をさらに定義できることを示唆しています。
For audio files, the recommendation is to provide mp3, m4a or mp4, or wav files [RFC2361], although the usage of sound (for example, a special ring tone for a particular caller) is not well defined in this specification. Future documents should consider both usage and potential security risks of playing sounds that are not specifically authorized by a device user.
オーディオファイルの場合、推奨事項はMP3、M4AまたはMP4、またはWAVファイル[RFC2361]を提供することですが、サウンドの使用（特定の発信者の特別な着信音）は、この仕様では十分に定義されていません。将来のドキュメントでは、デバイスユーザーによって特に承認されていない音の再生リスクと潜在的なセキュリティリスクの両方を考慮する必要があります。
Property cardinalities are indicated, for convenience, using the following notation and follow the guidance of jCard [RFC7095] and vCard [RFC6350], which is based on ABNF (see [RFC5234], Section 3.6):
利益のために、財産の基本は、次の表記法を使用して、JCard [RFC7095]およびVCARD [RFC6350]のガイダンスに従っています。
+=============+==================================================+
| Cardinality | Meaning |
+=============+==================================================+
| 1 | Exactly one instance per jCard MUST be present. |
+-------------+--------------------------------------------------+
| *1 | Exactly one instance per jCard MAY be present. |
+-------------+--------------------------------------------------+
| 1* | One or more instances per jCard MUST be present. |
+-------------+--------------------------------------------------+
| * | One or more instances per jCard MAY be present. |
+-------------+--------------------------------------------------+
Table 1
表1
The following properties, initially defined in [RFC6350], hold the identity information of the entity associated with the jCard. This subset of properties selected for this document are relevant to telephone and messaging applications.
[RFC6350]で最初に定義されている次のプロパティは、JCardに関連付けられたエンティティのID情報を保持します。このドキュメントで選択されたこのプロパティのサブセットは、電話およびメッセージングアプリケーションに関連しています。
The "fn" property provides formatted text corresponding to the name of the object the jCard represents. Reference: [RFC6350], Section 6.2.1.
「FN」プロパティは、JCardが表すオブジェクトの名前に対応するフォーマットされたテキストを提供します。参照：[RFC6350]、セクション6.2.1。
Value type: A single text value. Cardinality: 1*
値タイプ：単一のテキスト値。カーディナリティ：1*
Example: ["fn", {}, "text", "Mr. John Q. Public\, Esq."]
例：["fn"、{}、 "text"、 "Mr. John Q. public \、esq。"]]
The "n" property provides the components of the name of the object the jCard represents. Reference: [RFC6350], Section 6.2.2.
「n」プロパティは、JCardが表すオブジェクトの名前のコンポーネントを提供します。参照：[RFC6350]、セクション6.2.2。
Value type: A single structured text value. Each component can have multiple values. Cardinality: *1
値タイプ：単一の構造化されたテキスト値。各コンポーネントには複数の値を持つことができます。カーディナリティ： *1
Example:
["n", {}, "text", "Public;John;Quinlan;Mr.;Esq."]
["n", {}, "text", "Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."]
The "nickname" property provides the text corresponding to the nickname of the object the jCard represents. Reference: [RFC6350], Section 6.2.3.
「ニックネーム」プロパティは、JCardが表すオブジェクトのニックネームに対応するテキストを提供します。参照：[RFC6350]、セクション6.2.3。
Value type: One or more text values separated by a COMMA character (U+002C). Cardinality: *
値タイプ：コンマ文字（U+002C）で区切られた1つ以上のテキスト値。カーディナリティ： *
Example:
["nickname", {}, "text", "Robbie"]
["nickname", {}, "text", "Jim,Jimmie"]
["nickname", {}, "text", "TYPE=work:Boss"]
The "photo" property provides image or photograph information that annotates some aspect of the object the jCard represents. Reference: [RFC6350], Section 6.2.4.
「写真」プロパティは、JCardが表すオブジェクトの一部の側面に注釈を付ける画像または写真情報を提供します。参照：[RFC6350]、セクション6.2.4。
In addition to the definition of jCard, and to promote interoperability and proper formatting and rendering of images, the photo SHOULD correspond to a square image with the size of 128x128, 256x256, 512x512, or 1024x1024 pixels.
JCardの定義に加えて、相互運用性と適切なフォーマットと画像のレンダリングを促進するために、写真は128x128、256x256、512x512、または1024x1024ピクセルのサイズの正方形の画像に対応する必要があります。
Value type: A single URI. Cardinality: *
値タイプ：単一のURI。カーディナリティ： *
Example:
["photo", {}, "uri", "http://www.example.com/jqpublic-256x256.png"]
This property is concerned with information related to the delivery address of the jCard object.
このプロパティは、JCardオブジェクトの配信アドレスに関連する情報に関係しています。
The "adr" property provides the delivery address of the object the jCard represents. Reference: [RFC6350], Section 6.3.1.
「ADR」プロパティは、JCardが表すオブジェクトの配信アドレスを提供します。参照：[RFC6350]、セクション6.3.1。
Value type: A single structured text value separated by the SEMICOLON character (U+003B). Cardinality: *
値タイプ：セミコロン文字（U+003b）によって区切られた単一の構造化されたテキスト値。カーディナリティ： *
Example:
例：
["adr", {"type":"work"}, "text", ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008", "U.S.A."] ]
["adr"、{"type"： "work"}、 "text"、["" "、"、 "、" 3100マサチューセッツアベニューNW "、"ワシントン "、" dc "、" 20008 "、" U.S.A。
"adr" also allows a structured value element that itself has multiple values. In this case, the element of the array describing the structured value is itself an array with one element for each of the component's multiple values. The following example shows alternate values for the address string.
「ADR」は、それ自体が複数の値を持つ構造化された値要素を許可します。この場合、構造された値を記述する配列の要素自体は、コンポーネントの複数の値ごとに1つの要素を持つ配列です。次の例は、アドレス文字列の代替値を示しています。
Example:
例：
["adr", {"type":"work"}, "text", ["", "", ["3100 Massachusetts Avenue NW","Embassy of the United Kingdom"], "Washington", "DC", "20008", "U.S.A."] ]
["adr"、{"type"： "work"}、 "text"、["" "、"、["3100マサチューセッツアベニューNW"、「英国大使館 "]、「ワシントン」、「DC」、「20008」、「U.S.A.」]]]
These properties describe how to communicate with the object the jCard represents.
これらのプロパティは、JCardが表すオブジェクトと通信する方法を説明しています。
The "tel" property provides the telephone number for the object the jCard represents. Reference: [RFC6350], Section 6.4.1.
「Tel」プロパティは、JCardが表すオブジェクトの電話番号を提供します。参照：[RFC6350]、セクション6.4.1。
Relative to the SIP From header field value, this information may provide an alternate telephone number or other related telephone numbers for other uses.
ヘッダーフィールド値からのSIPと比較して、この情報は、他の用途の代替電話番号またはその他の関連電話番号を提供する場合があります。
It is important to note that any of the instances of the "tel" property should not be considered part of the authentication or verification part of STIR [RFC8224] or required to match the "orig" claim in the PASSporT [RFC8225]. These telephone numbers can be for contact, fax, or other purposes aligned with the general usage of jCard and vCard, but the potential confusion of the callee when provided with multiple telephone numbers instead of the actual, verified telephone number should be considered from a general policy point of view.
「Tel」プロパティのインスタンスのいずれも、STIR [RFC8224]の認証または検証の一部の一部と見なされるべきではないか、パスポートの「Orig」クレーム[RFC8225]に一致する必要があることに注意することが重要です。これらの電話番号は、JCARDとVCARDの一般的な使用法に合わせた連絡、FAX、またはその他の目的のためですが、実際の確認された電話番号の代わりに複数の電話番号を提供する場合のCalleeの潜在的な混乱は、一般的な方針の観点から考慮する必要があります。
Value type: By default, it is a single free-form text value (for backward compatibility with vCard 3), but it SHOULD be reset to a URI value. It is expected that the URI scheme will be "tel", as specified in [RFC3966], but other schemes MAY be used. Cardinality: *
値タイプ：デフォルトでは、単一のフリーフォームテキスト値（VCARD 3との後方互換性の場合）ですが、URI値にリセットする必要があります。[RFC3966]で指定されているように、URIスキームは「Tel」になると予想されますが、他のスキームが使用される場合があります。カーディナリティ： *
Example:
["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri",
"tel:+1-202-555-1000"]
["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"]
The "email" property provides the electronic mail address of the object the jCard represents. Reference: [RFC6350], Section 6.4.2.
「電子メール」プロパティは、JCardが表すオブジェクトの電子メールアドレスを提供します。参照：[RFC6350]、セクション6.4.2。
Value type: A single text value. Cardinality: *
値タイプ：単一のテキスト値。カーディナリティ： *
Example:
["email", {"type":"work"}, "text", "jqpublic@xyz.example.com"]
["email", {"pref":"1"}, "text", "jane_doe@example.com"]
The "lang" property indicates the language(s) that may be used for communicating with the object the jCard represents. Reference: [RFC6350], Section 6.4.4.
「Lang」プロパティは、JCardが表すオブジェクトと通信するために使用できる言語を示します。参照：[RFC6350]、セクション6.4.4。
Value type: A single language-tag value. Cardinality: *
値タイプ：単一の言語タグ値。カーディナリティ： *
Example:
["lang", {"type":"work", "pref":"1"}, "language-tag", "en"]
["lang", {"type":"work", "pref":"2"}, "language-tag", "fr"]
["lang", {"type":"home"}, "language-tag", "fr"]
These properties provide geographical information associated with the object the jCard represents.
これらのプロパティは、JCardが表すオブジェクトに関連付けられた地理的情報を提供します。
The "tz" property provides the time zone of the object the jCard represents. Reference: [RFC6350], Section 6.5.1.
「TZ」プロパティは、JCardが表すオブジェクトのタイムゾーンを提供します。参照：[RFC6350]、セクション6.5.1。
| Note: The reference for time-zone names is | <https://www.iana.org/time-zones>.
|注：タイムゾーン名の参照は|です<https://www.iana.org/time-zones>。
Value type: The default is a single text value. It can also be reset to a single URI or a UTC-offset value. Cardinality: *
値タイプ：デフォルトは単一のテキスト値です。また、単一のURIまたはUTCオフセット値にリセットすることもできます。カーディナリティ： *
Example: ["tz", {}, "text", "America/New_York"]
例：["tz"、{}、 "text"、 "America/new_york"]]
The "geo" property provides the global positioning of the object the jCard represents. Reference: [RFC6350], Section 6.5.2.
「Geo」プロパティは、JCardが表すオブジェクトのグローバルな位置付けを提供します。参照：[RFC6350]、セクション6.5.2。
Value type: A single URI. Cardinality: *
値タイプ：単一のURI。カーディナリティ： *
Example:
["geo", {}, "uri", "geo:37.386013,-122.082932"]
These properties are concerned with information associated with characteristics of the organization or organizational units of the object that the jCard represents.
これらのプロパティは、JCardが表すオブジェクトの組織または組織単位の特性に関連する情報に関係しています。
The "title" property provides the position or job of the object the jCard represents. Reference [RFC6350], Section 6.6.1.
「タイトル」プロパティは、JCardが表すオブジェクトの位置またはジョブを提供します。参照[RFC6350]、セクション6.6.1。
Value type: A single text value. Cardinality: *
値タイプ：単一のテキスト値。カーディナリティ： *
Example: ["title", {}, "text", "Research Scientist"]
例：["title"、{}、 "text"、 "Research Scientist"]]
The "role" property provides the position or job of the object the jCard represents. Reference [RFC6350], Section 6.6.2.
「役割」プロパティは、JCardが表すオブジェクトの位置またはジョブを提供します。参照[RFC6350]、セクション6.6.2。
Value type: A single text value. Cardinality: *
値タイプ：単一のテキスト値。カーディナリティ： *
Example: ["role", {}, "text", "Project Leader"]
例：["role"、{}、 "text"、 "Project Leader"]]
The "logo" property specifies a graphic image of a logo associated with the object the jCard represents. Reference [RFC6350], Section 6.6.3.
「ロゴ」プロパティは、JCardが表すオブジェクトに関連付けられたロゴのグラフィック画像を指定します。参照[RFC6350]、セクション6.6.3。
Value type: A single URI. Cardinality: *
値タイプ：単一のURI。カーディナリティ： *
Example:
["logo", {}, "uri", "http://www.example.com/abccorp-512x512.jpg"]
["logo", {}, "uri", "data:image/jpeg;base64,MIICajCCAdOgAwIBAgIC
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...the remainder of base64-encoded data...>"]
The "org" property specifies the organizational name and units of the object the jCard represents. Reference [RFC6350], Section 6.6.4.
「組織」プロパティは、JCardが表すオブジェクトの組織名と単位を指定します。参照[RFC6350]、セクション6.6.4。
Value type: A single structured text value consisting of components separated by the SEMICOLON character (U+003B). Cardinality: *
値タイプ：セミコロン文字（U+003b）で区切られたコンポーネントで構成される単一の構造化されたテキスト値。カーディナリティ： *
Example:
["org", {}, "text", "ABC\, Inc.;North American Division;Marketing"]
These properties provide additional information such as notes or revisions specific to the jCard.
これらのプロパティは、JCARDに固有のメモや改訂などの追加情報を提供します。
The "categories" property specifies application category information about the object the jCard represents. Reference: [RFC6350], Section 6.7.1.
「カテゴリ」プロパティは、JCardが表すオブジェクトに関するアプリケーションカテゴリ情報を指定します。参照：[RFC6350]、セクション6.7.1。
Value type: One or more text values separated by a COMMA character (U+002C). Cardinality: *
値タイプ：コンマ文字（U+002C）で区切られた1つ以上のテキスト値。カーディナリティ： *
Example: ["categories", {}, "text", "TRAVEL AGENT"]
例：["Categories"、{}、 "Text"、 "Travel Agent"]]
["categories", {}, "text", "INTERNET,IETF,INDUSTRY"]
[「カテゴリ」、{}、「テキスト」、「インターネット、IETF、産業」]]
The "note" property specifies supplemental information or a comment about the object the jCard represents. Reference: [RFC6350], Section 6.7.2.
「ノート」プロパティは、補足情報またはJCardが表すオブジェクトに関するコメントを指定します。参照：[RFC6350]、セクション6.7.2。
Value type: A single text value. Cardinality: *
値タイプ：単一のテキスト値。カーディナリティ： *
Example: ["note", {}, "text", "This fax number is operational 0800 to 1715 EST\, Mon-Fri."]
例：["note"、{}、 "text"、 "このファックス番号は、0800から1715 est \、mon-fri。"です。 "]]
The "sound" property specifies digital sound content information that annotates some aspect of the object the jCard represents. This property is often used to specify the proper pronunciation of the name property value of the jCard. Reference: [RFC6350], Section 6.7.5.
「sound」プロパティは、JCardが表すオブジェクトのいくつかの側面に注釈を付けるデジタルサウンドコンテンツ情報を指定します。このプロパティは、JCardの名前プロパティ値の適切な発音を指定するためによく使用されます。参照：[RFC6350]、セクション6.7.5。
Value type: A single URI. Cardinality: *
値タイプ：単一のURI。カーディナリティ： *
Example:
["sound", {}, "uri", "https://www.example.com/pub/logos
/abccorp.mp3"]
["sound", {}, "uri", "data:audio/basic;base64,MIICajCCAdOgAwIBA
gICBEAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvb
W11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiB
<...the remainder of base64-encoded data...>"]
The "uid" property specifies a globally unique identifier corresponding to the object the jCard represents. Reference: [RFC6350], Section 6.7.6.
「UID」プロパティは、JCardが表すオブジェクトに対応するグローバルに一意の識別子を指定します。参照：[RFC6350]、セクション6.7.6。
Value type: A single URI value. It MAY also be reset to free-form text. Cardinality: *1
値タイプ：単一のURI値。また、フリーフォームテキストにリセットされる場合があります。カーディナリティ： *1
Example:
["uid", {}, "uri", "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"]
The "url" property specifies a uniform resource locator associated with the object the jCard represents. Reference: [RFC6350], Section 6.7.8.
「URL」プロパティは、JCardが表すオブジェクトに関連付けられた均一なリソースロケーターを指定します。参照：[RFC6350]、セクション6.7.8。
There are potential security and privacy implications of providing URLs with telephone calls.
URLに電話をかけることには、セキュリティとプライバシーの潜在的な意味合いがあります。
The end client receiving a jCard with a "url" property MUST only display the URL and not automatically follow the URL or provide an automatic preview of the URL. In addition, it MUST generally adhere to good practice to make it clear to the user that it is their choice whether to follow the URL in a browser context consistent with all of the common browser security and privacy practices available on most consumer OS environments.
「URL」プロパティを備えたJCARDを受信するエンドクライアントは、URLのみを表示する必要があり、URLに自動的にフォローしたり、URLの自動プレビューを提供したりする必要があります。さらに、一般に、ほとんどの消費者OS環境で利用可能なすべての一般的なブラウザーセキュリティとプライバシープラクティスと一致するブラウザコンテキストでURLに従うかどうかをユーザーに明確にすることは、優れたプラクティスに従う必要があります。
Value type: A single uri value. Cardinality: *
値タイプ：単一のURI値。カーディナリティ： *
Example:
["url", {}, "uri", "https://example.org/french-rest/chezchic.html"]
The "version" property MUST be included and is intended to specify the version of the vCard specification used to format this vCard. Reference: [RFC6350], Section 6.7.9.
「バージョン」プロパティを含める必要があり、このVCardのフォーマットに使用されるVCard仕様のバージョンを指定することを目的としています。参照：[RFC6350]、セクション6.7.9。
Value type: A single text value. Cardinality: 1
値タイプ：単一のテキスト値。カーディナリティ：1
Example: ["version", {}, "text", "4.0"]
例：["version"、{}、 "text"、 "4.0"]]
Part of the intent of using jCard is to leverage its extensibility to define new properties to relay new information related to a caller. This capability is inherently supported as part of standard extensibility. However, usage of those new properties should be published and registered following [RFC7095], Section 3.6 or as defined in future specifications.
JCardを使用する意図の一部は、その拡張性を活用して新しいプロパティを定義して、発信者に関連する新しい情報を中継することです。この機能は、標準の拡張性の一部として本質的にサポートされています。ただし、これらの新しいプロパティの使用は、[RFC7095]、セクション3.6、または将来の仕様で定義されている後に公開および登録する必要があります。
This document defines the "jcard" value for the 'purpose' parameter of the Call-Info header field [RFC3261]. IANA has added this document to the list of references for the 'purpose' value of Call-Info in the "Header Field Parameters and Parameter Values" registry within the "Session Initiation Protocol (SIP) Parameters" registry group.
このドキュメントでは、コールINFOヘッダーフィールド[RFC3261]の「目的」パラメーターの「JCARD」値を定義します。IANAは、「セッション開始プロトコル（SIP）パラメーター」レジストリグループ内の「ヘッダーフィールドパラメーターとパラメーター値」レジストリの「ヘッダーフィールドパラメーターとパラメーター値」レジストリの「目的」値の「目的」値のリファレンスのリストにこのドキュメントを追加しました。
This document defines the 'call-reason' generic parameter for use in the Call-Info header field in the "Header Field Parameters and Parameter Values" registry defined by [RFC3968]. The parameter's token is "call-reason", and it takes the value of a quoted string.
このドキュメントでは、[RFC3968]で定義された「ヘッダーフィールドパラメーターとパラメーター値」レジストリで、コールINFOヘッダーフィールドで使用する「コールリアン」汎用パラメーターを定義します。パラメーターのトークンは「コールリアン」であり、引用された文字列の値が必要です。
+==============+================+===================+===========+
| Header Field | Parameter Name | Predefined Values | Reference |
+==============+================+===================+===========+
| Call-Info | call-reason | No | RFC 9796 |
+--------------+----------------+-------------------+-----------+
Table 2
表2
This document defines the 'verified' generic parameter for use in the Call-Info header field in the "Header Field Parameters and Parameter Values" registry defined by [RFC3968]. The parameter's token is "verified", and it takes the value of a quoted string that can only be "true".
このドキュメントでは、[RFC3968]で定義された「ヘッダーフィールドパラメーターとパラメーター値」レジストリで、コールINFOヘッダーフィールドで使用する「検証された」汎用パラメーターを定義します。パラメーターのトークンは「検証」されており、「True」のみにできる引用された文字列の値が必要です。
+==============+================+===================+===========+
| Header Field | Parameter Name | Predefined Values | Reference |
+==============+================+===================+===========+
| Call-Info | verified | Yes | RFC 9796 |
+--------------+----------------+-------------------+-----------+
Table 3
表3
This document defines the 'integrity' generic parameter for use as a new parameter in the Call-Info header field in the "Header Field Parameters and Parameter Values" registry defined by [RFC3968]. The parameter's token is "integrity", and it takes the value of a quoted string.
このドキュメントは、[RFC3968]で定義された「ヘッダーフィールドパラメーターとパラメーター値」レジストリのコールINFOヘッダーフィールドの新しいパラメーターとして使用する「整合性」の一般的なパラメーターを定義します。パラメーターのトークンは「整合性」であり、引用された文字列の値が必要です。
+==============+================+===================+===========+
| Header Field | Parameter Name | Predefined Values | Reference |
+==============+================+===================+===========+
| Call-Info | integrity | No | RFC 9796 |
+--------------+----------------+-------------------+-----------+
Table 4
表4
Revealing information such as the name, location, and affiliation of a person necessarily entails certain privacy risks. The SIP Call-Info header field has no particular confidentiality requirement, as the information sent in SIP is in the clear anyway. Transport-level security can be used to hide information from eavesdroppers, and the same confidentiality mechanisms would protect any Call-Info or jCard information carried or referred to in SIP.
人の名前、場所、所属などの情報を明らかにするには、必然的に特定のプライバシーリスクが必要です。SIP Call-INFOヘッダーフィールドには、SIPで送信された情報がとにかく明確になっているため、特別な機密性の要件はありません。トランスポートレベルのセキュリティを使用して盗聴者から情報を隠すことができ、同じ機密性メカニズムは、SIPで伝達または参照されているコールINFOまたはJCARD情報を保護します。
The use of the Call-Info header for transporting RCD ('rcd') is intended primarily for providing verified information at the termination of a call, where a verification service has a trusted UNI relationship with the user agent. To ensure the integrity and authenticity of this data, the security framework established by STIR, including the use of the 'rcd'PASSporT as defined in [RFC9795], should be followed. This framework enables digital signatures to verify the issuer of assertions related to the calling party's identity, distinguishing persistent identity attributes from transient, per-call details. Implementers should also consider certificate-based constraints to ensure proper binding between caller identity assertions and call-specific metadata while maintaining the integrity of the information throughout transmission. Since Call-Info serves as a means to convey verified caller information to the end user, mechanisms should be in place to validate the authenticity of the assertion, enforce appropriate certificate associations, and preserve the trustworthiness of RCD from origination to termination.
RCD（ 'RCD'）の輸送用コール-INFOヘッダーの使用は、主に、検証サービスがユーザーエージェントと信頼できるUNI関係を持っているコールの終了時に検証済みの情報を提供することを目的としています。このデータの整合性と信頼性を確保するには、[RFC9795]で定義されている「RCD」パスポートの使用を含むStirによって確立されたセキュリティフレームワークに従う必要があります。このフレームワークにより、デジタル署名は、通話当事者のアイデンティティに関連するアサーションの発行者を検証し、一時的な、一度の詳細と永続的なID属性を区別します。また、実装者は証明書ベースの制約を検討して、伝送全体の情報の整合性を維持しながら、発信者の身元アサーションとコール固有のメタデータ間の適切な拘束力を確保する必要があります。Call-INFOは、検証済みの発信者情報をエンドユーザーに伝える手段として機能するため、アサーションの信頼性を検証し、適切な証明書協会を実施し、RCDの信頼性を発信から終了まで維持するためのメカニズムを整える必要があります。
The SIP framework, defined in [RFC3261] and the various extensions to SIP which includes STIR [RFC8224] and RCD [RFC9795], has always provided mechanisms to assert information about the person or entity behind the call. This feature that can be a benefit to the SIP network that allows users to help identify the calling party behind an abstract telephone number. It can also enable the ability for actors to impersonate a calling party they are not authorized to represent. The core security consideration that has either explicitly or implicitly been acknowledged with any of the SIP and STIR specifications is that there be a management and policy layer that validates the participants in the ecosystem and their use of a SIP network with telephone number identifiers and identity-related information. Users should assess this risk and make the appropriate adjustments to validate proper participation while following these tools following these larger security, impersonation prevention, and privacy considerations.
[RFC3261]で定義されているSIPフレームワークと、攪拌[RFC8224]およびRCD [RFC9795]を含むSIPへのさまざまな拡張機能は、コールの背後にある人物またはエンティティに関する情報を主張するメカニズムを常に提供してきました。SIPネットワークにとって利益となるこの機能により、ユーザーは抽象的な電話番号の背後にある通話者の識別を支援できます。また、俳優が代表することを許可されていない呼び出しパーティーになりすましてもらうことができます。SIPおよびStim仕様のいずれかで明示的または暗黙的に認められている中心的なセキュリティの考慮事項は、エコシステムの参加者と電話番号識別子とID関連情報を備えたSIPネットワークの使用を検証する管理およびポリシーレイヤーがあることです。ユーザーは、このリスクを評価し、適切な調整を行い、適切な参加を検証し、これらのより大きなセキュリティ、なりすまし防止、プライバシーの考慮事項に従ってこれらのツールを追跡する必要があります。
The use of this specification with the insertion of metadata related to a caller or the purpose of the call should recognize the risk that this information can be viewed by those network elements and participants in the delivery of the SIP call. The insertion of media directly or via Base64 encoding or using a remote URI that query network resources should be considered as a potential threat vector to the user or user agent that could potentially allow the parsing of documents crafted to trigger a bug or install a virus. Remote access to URI content should additionally be considered as potentially exposing information about that user or user agent. Some sensitive users may desire the ability to control or disable these mechanisms entirely, and methods to restrict or disable the potential exposure should be considered to mitigate these concerns. Largely, any information that is included in RCD should be considered public, and this specification does not define any mechanism to protect this information beyond the security and privacy associated with the SIP signaling itself. This is a property that is consistent with SIP more generally, and this specification follows a similar pattern for its use.
発信者に関連するメタデータの挿入または呼び出しの目的を使用したこの仕様の使用は、SIPコールの配信において、これらのネットワーク要素と参加者がこの情報を表示できるリスクを認識する必要があります。ネットワークリソースをクエリするリモートURIを直接またはBase64を介してメディアを挿入することは、ユーザーまたはユーザーエージェントの潜在的な脅威ベクトルと見なされる必要があり、作成されたドキュメントの解析がバグをトリガーしたり、ウイルスを取り付けたりする可能性があります。URIコンテンツへのリモートアクセスは、そのユーザーまたはユーザーエージェントに関する情報を潜在的に公開する潜在的な情報と見なす必要があります。一部の機密ユーザーは、これらのメカニズムを完全に制御または無効にする能力を望んでいる場合があり、潜在的な露出を制限または無効にする方法は、これらの懸念を軽減するために考慮する必要があります。主に、RCDに含まれる情報は公開されるべきであり、この仕様は、SIPシグナル自体に関連するセキュリティとプライバシーを超えてこの情報を保護するメカニズムを定義するものではありません。これは、より一般的にSIPと一致するプロパティであり、この仕様はその使用のための同様のパターンに従います。
This specification contains the ability to include media resources and URI and URL resource references to media resources that could pose a threat when referencing or decoding the content of these media resources, which is similar to threats that web browsers and other media decoding applications must be concerned about. Network administrators should consider a network-specific set of policies or best practices for the use and hosting of media content that is agreed to contain validated media resources that have been evaluated to not pose a security threat to the participants or the devices supported in the ecosystem.
この仕様には、メディアリソースとURIおよびURLリソースの参照を含める機能が含まれています。メディアリソースには、これらのメディアリソースのコンテンツを参照またはデコードするときに脅威をもたらす可能性があります。ネットワーク管理者は、参加者またはエコシステムでサポートされているデバイスにセキュリティの脅威をもたらさないと評価されている検証済みのメディアリソースを含めることに合意されたメディアコンテンツの使用とホスティングのためのネットワーク固有のポリシーまたはベストプラクティスを考慮する必要があります。
[ISOPNG] ISO/IEC, "Information technology -- Computer graphics and image processing -- Portable Network Graphics (PNG), Functional specification", ISO/IEC 15948:2004, March 2004, <https://www.iso.org/standard/29581.html>.
[ISOPNG] ISO/IEC、「情報技術 - コンピューターグラフィックスと画像処理 - ポータブルネットワークグラフィックス（PNG）、機能仕様」、ISO/IEC 15948：2004、2004年3月、<https://www.org/standard/29581.html>。
[ITUJPEG] ITU-T, "Information technology - Digital compression and coding of continuous-tone still images: JPEG File Interchange Format (JFIF)", ITU-T Recommendation T.871, ISO/IEC 10918-5, May 2013, <https://www.itu.int/rec/T-REC-T.871-201105-I/en>.
[itujpeg] itu-t、「情報技術 - 連続トーン静止画像のデジタル圧縮とコーディング：JPEGファイルインターチェンジ形式（JFIF）」、ITU-T推奨T.871、ISO/IEC 10918-5、2013年
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/rfc2119>
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, <https://www.rfc-editor.org/info/rfc2392>.
[RFC2392] Levinson、E。、「コンテンツIDおよびメッセージIDユニフォームリソースロケーター」、RFC 2392、DOI 10.17487/RFC2392、1998年8月、<https://www.rfc-editor.org/info/rfc2392>
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESS SESSION INTIATION Protocol"、RFC 3261、DOI 10.17487/RFC3261、6月2002年、RFC3261、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <https://www.rfc-editor.org/info/rfc3966>.
[RFC3966] Schulzrinne、H。、「電話番号のTel URI」、RFC 3966、DOI 10.17487/RFC3966、2004年12月、<https://www.rfc-editor.org/info/rfc3966>
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, DOI 10.17487/RFC3968, December 2004, <https://www.rfc-editor.org/info/rfc3968>.
[RFC3968] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）の番号が割り当てられたヘッダーフィールドパラメーターレジストリ」、BCP 98、RFC 3968、DOI 10.17487/RFC3968、2004年12月、<https://www.rfc-editor.org/info/rfc3968>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64 Data Encodings」、RFC 4648、DOI 10.17487/RFC4648、2006年10月、<https://www.rfc-editor.org/info/rfc4648>
[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>.
[RFC5234] Crocker, D., Ed.P. Overell、「構文仕様のための拡張BNF：ABNF：STD 68、RFC 5234、DOI 10.17487/RFC5234、2008年1月、<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>.
[RFC6350] Perreault、S。、「VCard形式の仕様」、RFC 6350、DOI 10.17487/RFC6350、2011年8月、<https://www.rfc-editor.org/info/rfc6350>。
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, DOI 10.17487/RFC7095, January 2014, <https://www.rfc-editor.org/info/rfc7095>.
[RFC7095] Kewisch、P。、「JCard：VCardのJSON形式」、RFC 7095、DOI 10.17487/RFC7095、2014年1月、<https://www.rfc-editor.org/info/rfc7095>
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.
[RFC7519] Jones、M.、Bradley、J。、およびN. Sakimura、「JSON Web Token（JWT）」、RFC 7519、DOI 10.17487/RFC7519、2015年5月<https://www.rfc-editor.org/-rfc7519>
[RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and J. Winterbottom, "Additional Data Related to an Emergency Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, <https://www.rfc-editor.org/info/rfc7852>.
[RFC7852] Gellens、R.、Rosen、B.、Tschofenig、H.、Marshall、R.、およびJ. Winterbottom、「緊急コールに関連する追加データ」、RFC 7852、DOI 10.17487/RFC7852、2016年7月、<https:/
[RFC7903] Leonard, S., "Windows Image Media Types", RFC 7903, DOI 10.17487/RFC7903, September 2016, <https://www.rfc-editor.org/info/rfc7903>.
[RFC7903] Leonard、S。、「Windows Image Media Type」、RFC 7903、DOI 10.17487/RFC7903、2016年9月、<https://www.rfc-editor.org/info/rfc7903>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、5月、<https://www.rfc-editor.org/info/-urfc8174>
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, <https://www.rfc-editor.org/info/rfc8224>.
[RFC8224] Peterson、J.、Jennings、C.、Rescorla、E.、およびC. Wendt、「セッション開始プロトコル（SIP）で認証されたアイデンティティ管理」、RFC 8224、DOI 10.17487/RFC8224、2018年2月、<https://www.rfc-editor.org/info/rfc8224>。
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, <https://www.rfc-editor.org/info/rfc8225>.
[RFC8225] Wendt、C。and J. Peterson、「Passport：Personal Assertion Token」、RFC 8225、DOI 10.17487/RFC8225、2018年2月、<https://www.rfc-editor.org/info/rfc825>
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T.、ed。、「JavaScriptオブジェクト表記（JSON）データインターチェンジ形式」、STD 90、RFC 8259、DOI 10.17487/RFC8259、2017年12月、<https://www.rfc-editor.org/info/RFC8259>
[RFC9795] Wendt, C. and J. Peterson, "Personal Assertion Token (PASSporT) Extension for Rich Call Data", RFC 9795, DOI 10.17487/RFC9795, July 2025, <https://www.rfc-editor.org/info/rfc9795>.
[RFC9795] Wendt、C。and J. Peterson、「リッチコールデータの個人的アサーショントークン（パスポート）拡張機能」、RFC 9795、DOI 10.17487/RFC9795、2025年7月、<https://www.rfc-editor.org/info/rfc9795>。
[W3C-SRI] Akhawe, D., Ed., Braun, F., Ed., Marier, F., Ed., and J. Weinberger, Ed., "Subresource Integrity", W3C Recommendation, 23 June 2016, <https://www.w3.org/TR/2016/REC-SRI-20160623/>.
[W3C-SRI] Akhawe、D.、ed。、Braun、F.、Ed。、Marier、F.、Ed。、およびJ. Weinberger、ed。、「Subresource Integrity」、W3C推奨、2016年6月23日、<https://www.w3.org/tr/2016/REC-SRI-20160623/>。
[W3C-SVGTiny1.2] Anderssone, O., Ed., Berjon, R., Ed., Dahlstrm, E., Ed., Emmons, A., Ed., Ferraiolo, J., Ed., Grasso, A., Ed., Hardy, V., Ed., Hayman, S., Ed., Jackson, D., Ed., Lilley, C., Ed., McCormack, C., Ed., Neumann, A., Ed., Northway, C., Ed., Quint, A., Ed., Ramani, N., Ed., Schepers, D., Ed., and A. Shellshear, Ed., "Scalable Vector Graphics (SVG) Tiny 1.2 Specification", W3C Recommendation, 22 December 2008, <https://www.w3.org/TR/2008/REC-SVGTiny12-20081222/>.
[W3C-SVGTINY1.2] Anderssone、O.、ed。、Berjon、R.、ed。、Dahlstrm、E.、Ed。、Emmons、A.、Ed。、Ferraiolo、J.、Ed。、Grasso、A.、Ed。、Hardy、V.、ed。、Hayman、S.、ed。Neumann、A.、ed。、Ed。、Northway、C.、ed。、Quint、A.、ed。、Ramani、N.、ed。、Schepers、D.、and、A。Shellshear、ed。、「Scalable Vector Graphics（SVG）Tiny 1.2 Specification」、W3C推奨、2008年12月22日、<https://www.w3.org/tr/2008/rec-svgtiny12-20081222/>。
[RFC2361] Fleischman, E., "WAVE and AVI Codec Registries", RFC 2361, DOI 10.17487/RFC2361, June 1998, <https://www.rfc-editor.org/info/rfc2361>.
[RFC2361] Fleischman、E。、「Wave and Avi Codec Registries」、RFC 2361、DOI 10.17487/RFC2361、1998年6月、<https://www.rfc-editor.org/info/rfc2361>。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <https://www.rfc-editor.org/info/rfc3325>.
[RFC3325] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内の主張されたアイデンティティのセッション開始プロトコル（SIP）のプライベートエクステンション」、RFC 3325、DOI 10.17487/RFC3325、2002年11月、<https://www.rfc-editor.org/info/rfc3325>。
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, September 2014, <https://www.rfc-editor.org/info/rfc7340>.
[RFC7340] Peterson、J.、Schulzrinne、H。、およびH. Tschofenig、「安全な電話IDの問題と要件」、RFC 7340、DOI 10.17487/RFC7340、2014年9月、<https://www.rfc-editor.org/info/-urfc7340>
Acknowledgements
謝辞
We would like to thank David Hancock, Alec Fenichel, Paul Kyzivat, Yi Jing and other members of the SIPCORE and STIR working groups and ATIS/SIP Forum IPNNI for their helpful suggestions and comments during the creation of this document.
この文書の作成中に有益な提案とコメントについて、David Hancock、Alec Fenichel、Paul Kyzivat、Yi Jing、およびSipcore and Stir Working Group and ATIS/SIPフォーラムIPNNIのメンバーに感謝します。
Authors' Addresses
著者のアドレス
Chris Wendt Somos United States of America Email: chris@appliedbits.com
Chris Wendt Somos United States of America Email：chris@appliedbits.com
Jon Peterson TransUnion United States of America Email: jon.peterson@transunion.com
Jon Peterson Transunion United States of America Email：jon.peterson@transunion.com