Network Working Group G. Vaudreuil
Request for Comments: 4237 Lucent Technologies
Category: Standards Track October 2005
Voice Messaging Directory Service
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document provides details of the Voice Profile for Internet Mail (VPIM) directory service. The service provides the email address of the recipient that is given a telephone number. It optionally provides the spoken name of the recipient and the media capabilities of the recipient.
この文書は、インターネットメール（VPIM）ディレクトリサービスのための音声プロファイルの詳細を提供します。サービスは、電話番号が付与され、受信者の電子メールアドレスを提供します。それは、必要に応じて、受信者の音声名と受信者のメディア機能を提供します。
The VPIM directory Schema provides essential additional attributes to recreate the voice mail user experience using standardized directories. This user experience provides, at the time of addressing, basic assurances that the message will be delivered as intended. This document combines two earlier documents, one from Anne Brown and one from Greg Vaudreuil, that define a voice messaging schema into a single working group submission.
VPIMディレクトリスキーマは、標準化されたディレクトリを使用してボイスメールユーザ体験を再現するために不可欠な追加属性を提供します。このユーザーエクスペリエンスは、意図したとおりに、メッセージが配信されることの基本的な保証を扱う時には、用意されています。この文書は、単一のワーキンググループの提出にボイスメッセージのスキーマを定義する2つの以前の文書、アン・ブラウンから1とグレッグヴォードルイユから1を、兼ね備えています。
Table of Contents
目次
1. Scope ...........................................................2
1.1. Design Goals ...............................................2
1.2. Performance Constraints ....................................2
1.3. Scaling Constraints ........................................3
1.4. Reliability Constraints ....................................3
2. The VPIMUser Directory Schema ...................................3
2.1. vPIMTelephoneNumber ........................................4
2.2. vPIMRfc822Mailbox ..........................................4
2.3. vPIMSpokenName .............................................4
2.4. vPIMTextName ...............................................5
2.5. vPIMSupportedAudioMediaTypes ...............................5
2.6. vPIMSupportedMessageContext ................................5
2.7. vPIMExtendedAbsenceStatus ..................................6
2.8. vPIMSupportedUABehaviors ...................................6
2.9. vPIMMaxMessageSize .........................................7
2.10. vPIMSubMailboxes ..........................................8
3. Security Considerations .........................................8
4. IANA Considerations .............................................9
4.1. Object Identifiers .........................................9
4.2. Object Identifier Descriptors ..............................9
5. References .....................................................10
5.1. Normative References ......................................10
5.2. Informative References ....................................10
The VPIM directory Schema (VPIMDIR) is accessed from outside the enterprise or service provider domain using the recipient's telephone number.
VPIMディレクトリスキーマ（VPIMDIR）は、受信者の電話番号を使用して、企業またはサービスプロバイダドメインの外部からアクセスされます。
Once the identity of the VPIM directory server is known, the email address, capabilities, and spoken name confirmation information can be retrieved. This query is expected to use LDAP [LDAP], a connection-oriented protocol. The protocol transaction includes multiple packet round-trips to execute the query and retrieval and is considered to be the highest latency element of the messaging service. Further, retrieval of the confirmation information may require the return of a spoken name segment of up to 20kbytes (5 seconds at 4kbytes/second). Over a sufficiently engineered Internet connection, a 1250 ms response time is believed to be achievable over the Internet at large.
VPIMディレクトリサーバの身元が分かったら、電子メールアドレス、機能、および音声名の確認情報を取得することができます。このクエリは、LDAP [LDAP]、コネクション指向のプロトコルを使用することが期待されています。プロトコルのトランザクションは、クエリと検索を実行するために、複数のパケットラウンドトリップが含まれており、メッセージングサービスの最高待ち時間の要素であると考えられています。さらに、確認情報の検索は20kbytesまでの音声名セグメントのリターン（4Kバイトで5秒/秒）を必要とするかもしれません。十分に設計され、インターネット接続を介して、1250ミリ秒の応答時間は、広くインターネット上で達成可能であると考えられています。
A service provider's namespace is expected to include entries for tens of millions of subscribers in a flat namespace based on the VPIM inter-domain address form: telephone_number@domain_name. A large corporation may have a hundred-thousand entries, while a large service provider may have tens of millions of entries in a single domain. It is expected that there will be a single public address validation service for a given service provider's network. It is believed that existing directory technology, including horizontal scalability through replication, will provide sufficient transaction throughput within the required latency requirements to address this need. The only fundamental, new requirement this application imposes on directory servers, beyond similar existing services, is the ability to return the recipient's spoken name. Preliminary investigation suggests that storage and retrieval of a spoken name will not add appreciable latency; however, it will add to the need for storage capacity.
TELEPHONE_NUMBERする@ DOMAIN_NAME：サービスプロバイダの名前空間は、VPIMドメイン間のアドレス形式に基づいて、フラットな名前空間に数十数百万の加入者のためのエントリを含めることが予想されます。大規模なサービスプロバイダは、単一のドメイン内のエントリの数千万人を持っているかもしれないが、大企業は、百千のエントリを有することができます。特定のサービスプロバイダのネットワークのための単一のパブリックアドレス検証サービスがあることが予想されます。複製を通る水平スケーラビリティを含め、ディレクトリ技術を既存のは、このニーズに応えるために必要な待ち時間の要件の範囲内で十分なトランザクション・スループットを提供すると考えられています。このアプリケーションは、類似の既存のサービスを超えて、ディレクトリサーバーに課すだけで基本的な、新しい要件は、受信者の音声名を返す機能です。予備調査は、音声名の保存と検索がかなりの遅延を追加しないであろうことを示唆しています。しかし、それはストレージ容量が必要に追加されます。
DNS provides well-documented redundancy and load-balancing capabilities for the VPIMDIR. However, the latency requirements to the end-user may not permit client-side fail-over to a secondary server and may require the directory server to be implemented as a high-availability service.
DNSは十分に文書化、冗長性とVPIMDIRのロードバランシング機能を提供します。しかし、エンドユーザーへの遅延要件は、クライアント側のフェイルオーバーセカンダリサーバに許可することはできませんし、ディレクトリサーバは、高可用性サービスとして実装する必要があります。
(IANA-ASSIGNED-OID.1 NAME 'vPIMUser'
SUP 'top'
AUXILIARY
MUST ( vPIMRfc822Mailbox $
vPIMTelephoneNumber )
MAY ( vPIMSpokenName $
vPIMSupportedUABehaviors $
vPIMSupportedAudioMediaTypes $
vPIMSupportedMessageContext $
vPIMTextName $
vPIMExtendedAbsenceStatus $
vPIMMaxMessageSize $
vPIMSubMailboxes ) )
When present, the vPIMUser object contains information useful for verifying that the dialed telephone number corresponds to the intended recipient. This object also provides capability information and mailbox status information useful for guiding composition by the sender and for setting delivery expectations at sending time.
存在する場合、vPIMUserオブジェクトは、ダイヤルされた電話番号は、意図された受取人に対応することを検証するための有用な情報を含んでいます。このオブジェクトはまた、送信者が組成物を案内すると時間を送信で配信期待を設定するための有用な機能情報とメールボックスのステータス情報を提供します。
The attribute vPIMTelephoneNumber is the full E.164 form of the telephone number [E164], including any sub-addressing portion. The normal search will be for this attribute.
属性vPIMTelephoneNumberは[E164]、任意のサブアドレッシング部を含む電話番号の完全なE.164形式です。通常の検索では、この属性になります。
(IANA-ASSIGNED-OID.2.1 NAME 'vPIMTelephoneNumber' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{20} )
（IANAによって割り当てられ-OID.2.1 NAME 'vPIMTelephoneNumber' 平等caseIgnoreMatch構文は1.3.6.1.4.1.1466.115.121.1.44 {20}）
Example: A North American telephone number with the sub address of 12 would be represented as "+12145551212+12".
例：12のサブアドレスを持つ北米の電話番号は、「+ 12 + 12145551212」として表現されます。
Note that vPIMTelephoneNumber is, by default, a multi-valued attribute. But if an entry has multiple values for this attribute, those values MUST be distinct from each other in the telephone number portion. It is expected that each submailbox of a single telephone number will have its own vPIMUser entry.
デフォルトでは、vPIMTelephoneNumberであることに注意してください、複数の値を持つ属性。エントリは、この属性に対して複数の値を持つ場合は、それらの値は、電話番号の部分で互いに異なるものでなければなりません。単一の電話番号の各サブメールボックスは、独自のvPIMUserエントリを持つことが期待されます。
The vPIMTelephoneNumber differs from telephoneNumber in [LDAP] in its support for sub-addressing information and its use as a voice messaging address. In most cases, these values will be the same.
vPIMTelephoneNumberは、サブアドレス情報と音声メッセージングアドレスとしての使用のためにそのサポートに[LDAP]にtelephoneNumberのとは異なります。ほとんどの場合、これらの値は同じになります。
The telephone number is stored with no parenthesis, spaces, dots, or hyphens. The leading '+' and the '+' delineating the submailbox are required markup.
電話番号はありません括弧、スペース、ドット、またはハイフンで保存されています。先頭に「+」と「+」線引きサブメールボックスには、マークアップを必要としています。
The attribute vPIMRfc822Mailbox stores the inter-domain SMTP address of the voice mailbox associated with a given telephone number. It is defined as a distinct attribute to distinguish it from the rfc822Mailbox attribute that may be used for other purposes. Although it would be preferable to define vPIMRfc822Mailbox as a subtype of rfc822Mailbox, it is defined here as an entirely new attribute because some directory implementations do not support sub-typing.
属性vPIMRfc822Mailboxは、与えられた電話番号に関連付けられているボイスメールボックスのドメイン間のSMTPアドレスを格納します。他の目的に使用することができるrfc822Mailbox属性からそれを区別するために別個の属性として定義されます。それはrfc822MailboxのサブタイプとしてvPIMRfc822Mailboxを定義することが好ましいが、いくつかのディレクトリの実装はサブタイピングをサポートしていないので、それは完全に新しい属性として定義されます。
(IANA-ASSIGNED-OID.2.2 NAME 'vPIMRfc822Mailbox' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
（IANAによって割り当てられ-OID.2.2 NAME 'vPIMRfc822Mailbox' 平等caseIgnoreIA5Match構文は1.3.6.1.4.1.1466.115.121.1.26 {256}）
The vPIMSpokenName attribute is an octet string and MUST be encoded in 32 kbit/s ADPCM exactly, as defined by [32KADPCM]. vPIMSpokenName shall contain the spoken name of the user in the voice of the user. The length of the spoken name segment MUST NOT exceed five seconds.
vPIMSpokenName属性は、オクテットストリングであり、[32KADPCM]によって定義されるように、正確に32キロビット/秒のADPCMで符号化されなければなりません。 vPIMSpokenNameは、ユーザーの声に、ユーザの音声名を含まなければなりません。音声名セグメントの長さが5秒を超えてはなりません。
Private or additional encoding types are outside the scope of this version.
プライベートまたは追加の符号化タイプは、このバージョンの範囲外です。
(IANA-ASSIGNED-OID.2.3 NAME 'vPIMSpokenName' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{20000} SINGLE-VALUE )
（IANAによって割り当てられ-OID.2.3名 'vPIMSpokenName' 平等octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 {20000}単一値）
The text name is designed to be consistent with the unstructured text name databases used for calling name delivery service of caller ID.
テキスト名は、発信者IDの名前配信サービスを呼び出すために使用され、非構造化テキスト名のデータベースと一致するように設計されています。
(IANA-ASSIGNED-OID.2.4 NAME 'vPIMTextName' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE )
（IANAによって割り当てられ-OID.2.4名 'vPIMTextName' 平等caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 {20}単一値）
The vPIMSupportedAudioMediaTypes attribute indicates the type(s) of audio encodings that can be received at the address specified in vPIMRfc822Mailbox.
vPIMSupportedAudioMediaTypes属性はvPIMRfc822Mailboxで指定されたアドレスで受信することができるオーディオエンコーディングのタイプ（複数可）を示しています。
(IANA-ASSIGNED-OID.2.5 NAME 'vPIMSupportedAudioMediaTypes' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
（IANAによって割り当てられ-OID.2.5 NAME 'vPIMSupportedAudioMediaTypes' 平等caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26）
This is a multi-value attribute. The allowable values for this attribute are the MIME audio subtypes registered with IANA. Non-standard and private encoding types must be indicated by prepending the new type name with either "X-" or "x-".
これは、複数値の属性です。この属性の許容値は、IANAに登録されたMIMEオーディオサブタイプです。非標準およびプライベートのエンコードタイプは「X-」または「X-」のいずれかで新しいタイプ名を付加することで示されなければなりません。
Because ADPCM is a required format, the audio32kadpcm value must be listed if this attribute is present.
ADPCMが必要な形式であるため、この属性が存在する場合、audio32kadpcm値がリストされている必要があります。
The message context provides guidance to the sender about the message contexts the recipient is likely to accept. Message context provides less precise information about a given recipient's capabilities than a list of media types. However, given the growing role of media-conversion gateways, the context indicator provides more useful guidance to a sender in a "unified messaging" environment.
メッセージは、受信者が受け取りやすいコンテキストについてメッセージコンテキストは、送信者へのガイダンスを提供します。メッセージコンテキストは、メディアタイプのリストより与えられた受信者の機能についてはあまり正確な情報を提供します。しかし、メディア変換ゲートウェイの成長の役割を与えられた、コンテキストインジケータは、「ユニファイドメッセージング」環境での送信者へのより多くの有用な指針を提供します。
(IANA-ASSIGNED-OID.2.6 NAME 'vPIMSupportedMessageContext' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
（IANAによって割り当てられ-OID.2.6名 'vPIMSupportedMessageContext' 平等caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26）
This is a multi-value attribute. The set of valid message context values is defined in [CONTEXT].
これは、複数値の属性です。有効なメッセージコンテキスト値の集合は[コンテキスト]で定義されています。
It is common to have an attribute that indicates to the subscriber whether the recipient is accepting messages during his absence. This feature -- called "extended absence" -- provides an advisory message at sending time. It is similar in concept to "vacation notices" common for textual email, but has its own cultural and operational nuances.
受信者が彼の不在時のメッセージを受け付けているかどうかを加入者に示す属性を持つことが一般的です。この機能 - 「長期不在」と呼ばれる - は、時間を送ることに助言メッセージを提供します。これは、テキスト形式の電子メールのための共通の「休暇の通知」の概念と似ていますが、独自の文化や運用ニュアンスを持っています。
(IANA-ASSIGNED-OID.2.7 NAME 'vPIMExtendedAbsenceStatus' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
（IANAによって割り当てられ-OID.2.7名 'vPIMExtendedAbsenceStatus' 平等caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26単一値）
The three values defined are:
定義された三つの値は以下のとおりです。
"Off", "On", "MsgBlocked"
"オフ"、 "オン"、 "MsgBlocked"
"Off" indicates that the recipient either does not support extended absence or has not set such an indicator. "Off" is the default condition if this attribute is not returned.
「オフ」は、受信者が長期不在をサポートしていない、またはそのような区分を設定していないいずれかのことを示しています。この属性が返されない場合はデフォルトの「オフ」状態です。
"On" indicates that the recipient has set an extended absence indicator, but the mailbox is still accepting messages for review at an unspecified future time.
「オン」、受信者が長期不在の指標を設定しましたが、メールボックスがまだ指定されていない将来の時点でレビューのためにメッセージを受け入れていることを示しています。
"MsgBlocked" indicates that the recipient has set an extended absence indicator and the mailbox is currently configured to reject incoming messages. Messages SHOULD NOT be sent to the recipient if this value is returned in the vPIMExtendedAbsenceStatus attribute.
「MsgBlocked」は、受信者が長期不在インジケータを設定しており、メールボックスが現在の着信メッセージを拒否するように構成されていることを示しています。この値はvPIMExtendedAbsenceStatus属性に返された場合、メッセージは受信者に送るべきではありません。
Internet mail does not provide facilities for the sender to know whether the recipient supports a number of optional features that can be requested or indicated in the RFC822 headers. This attribute provides a list of the attributes, considered optional by VPIM and other vendor-specific attributes, that may be supported by the recipient. If this attribute is not supported, only those attributes listed as mandatory in VPIM are assumed to be supported. Undisclosed behaviors may be indicated in the RFC822 message; however, there is no assurance by the receiving system of their support.
インターネットメールは、受信者がRFC822ヘッダに要求または指示することができるオプション機能の数をサポートしているかどうかを知るために、送信者のための施設を提供していません。この属性は、受信者に支持されてVPIMおよびその他のベンダー固有の属性ではオプションと見なさ属性のリストを提供します。この属性がサポートされていない場合、VPIMに必須と記載されている属性のみがサポートされているものとします。非公開動作はRFC822メッセージに示されてもよいです。しかし、彼らのサポートの受信システムによって保証はありません。
(IANA-ASSIGNED-OID.2.8 NAME 'vPIMSupportedUABehaviors' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
（IANAによって割り当てられ-OID.2.8 NAME 'vPIMSupportedUABehaviors' 平等caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26）
The following behaviors are defined:
以下の動作が定義されています。
MessageDispositionNotification
MessageSensitivity
MessageImportance
The presence of the MessageDispositionNotification value indicates that the recipient will send an MDN in response to an MDN request.
MessageDispositionNotification値の存在は、受信者がMDN要求に応答してMDNを送信することを示しています。
MessageSensitivity indicates that the recipient fully supports the sensitivity indication as defined in VPIM [VPIMV2].
MessageSensitivityは、受信者が完全[VPIMV2] VPIMで定義されるように、感度表示をサポートしていることを示しています。
MessageImportance indicates that the recipient fully supports the importance indication as defined in VPIM [VPIMV2].
MessageImportanceは、受信者が完全[VPIMV2] VPIMで定義されるように重要性の指標をサポートしていることを示しています。
These may be further extended without standardization to include proprietary user interface functional extensions. These proprietary extension values must be prefixed with an "X-" or "x-".
これらは、さらに、独自のユーザインタフェース機能拡張を含むように標準化することなく、拡張することができます。これらの独自拡張の値は、「x-」又は「X-」を付ける必要があります。
At the time of composition, the message can be checked for acceptable length using the maximum message size attribute. Maximum message size is an attribute usually configured by policy of the receiving system, typically in units of minutes. While ESMTP provides a mechanism to determine if a message is too long in bytes, it is an unreliable guide for the composer when multiple encodings, multiple media, or variable bit-rate encodings are supported.
組成時に、メッセージは、最大メッセージサイズ属性を使用して、許容される長さをチェックすることができます。最大メッセージサイズは、通常、典型的には分単位で、受信システムのポリシーによって設定属性です。 ESMTPメッセージはバイト単位で長すぎるかどうかを決定するためのメカニズムを提供しながら、複数のエンコーディング、複数のメディア、または可変ビットレートエンコーディングがサポートされている場合には、作曲のために信頼できないガイドです。
(IANA-ASSIGNED-OID.2.9 NAME 'vPIMMaxMessageSize' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
（IANAによって割り当てられ-OID.2.9名 'vPIMMaxMessageSize' 平等integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27単一値）
The attribute indicates the maximum message length in seconds that the receiving mailbox may receive.
属性は、受信メールボックスが受け取ることが秒単位での最大メッセージ長を示します。
This attribute indicates the presence of sub-mailboxes for the queried telephone number. This information may be used to provide a post-dial sub-addressing menu to the sender.
この属性は、照会の電話番号のためのサブメールボックスの存在を示します。この情報は、送信者にポストダイヤルサブアドレッシングメニューを提供するために使用することができます。
(IANA-ASSIGNED-OID.2.10 NAME 'vPIMSubMailboxes' EQUALITY numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{4} )
（IANAによって割り当てられ-OID.2.10 NAME 'vPIMSubMailboxes' 平等numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 {4}）
The allowable values include a list of sub-mailbox numbers with a numeric range of 1-9999. The user interface may use this information to prompt the sender to select a sub-mailbox. Spoken names associated with each sub-mailbox may be individually retrieved by subsequent queries to the recipient's VPIMDIR service.
許容値は1から9999までの数値範囲とサブメールボックス番号のリストが含まれています。ユーザーインターフェースは、サブメールボックスを選択するために、送信者を促すために、この情報を使用することができます。各サブメールボックスに関連付けられた発話名を個別に受信者のVPIMDIRサービスへの後続のクエリによって取得することができます。
The following are known security issues.
以下は、既知のセキュリティ上の問題です。
1) Service provider customer information is very sensitive, especially in this time of local phone competition. Service providers require maximum flexibility to protect this data. Because of the dense nature of telephone number assignments, this data is subject to "go fish" queries via repeated LDAP queries to determine a complete list of current or active messaging subscribers. To reduce the value of this retrieved data, service providers may limit disclosure of data that is useful for telemarketing, such as the textual name, and may disclose only information useful to the sender, such as the recipient's spoken name, a data element that is much harder to auto-process.
1）サービスプロバイダーの顧客情報は、特にローカル電話の競争のこの時期に、非常に敏感です。サービスプロバイダは、このデータを保護するために最大限の柔軟性が必要です。そのため、電話番号の割り当ての密な性質のため、このデータは、現在またはアクティブなメッセージングの加入者の完全なリストを決定するために繰り返してLDAPクエリを介して、クエリ「魚を行く」の対象です。この取得されたデータの値を小さくするために、サービスプロバイダは、このようなテキスト形式の名前として、テレマーケティングのために有用であるデータの開示を制限すること、および、そのような受信者の音声名、あるデータ要素として送信者に有益な情報のみを開示することがあります自動プロセスにはるかに困難。
2) In many countries, there are privacy laws or regulations that prohibit disclosure of certain kinds of descriptive information (e.g., text names). Hence, server implementors are encouraged to support DIT structural rules and name forms [LDAPMODELS] as these provide a mechanism for administrators to select appropriate naming attributes for entries. Administrators are encouraged to use these mechanisms, access controls, and other administrative controls, which may be available to restrict use of attributes containing sensitive information when naming entries.
2）多くの国では、記述情報（例えば、テキスト名）のある種の開示を禁止するプライバシー法や規制があります。このため、サーバーの実装者は、これらのようLDAPMODELS] DIT構造規則や名前形式をサポートすることが奨励されたエントリのための適切な命名属性を選択するには、管理者のためのメカニズムを提供します。管理者は、エントリに名前を付けるときに、機密情報を含む属性の使用を制限するために利用可能であり、これらのメカニズム、アクセス制御、およびその他の管理コントロールを、使用することをお勧めします。
3) The LDAP directory service needs to be secured properly for this intended use. [LDAPAUTH] describes a number of considerations that apply in this use. In particular, this service provides unauthenticated, public access to directory data, and as such, it is vulnerable to attacks that redirect the query to a rogue server and offer malicious data.
3）LDAPディレクトリサービスは、この意図された用途に対して適切に確保する必要があります。 [LDAPAUTH]この使用に適用検討事項の数を示します。具体的には、このサービスは、ディレクトリデータへの認証されていない、パブリックアクセスを提供し、そのように、それは不正なサーバへのクエリをリダイレクトし、悪質なデータを提供する攻撃に対して脆弱です。
Reference RFC 3383 "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)" [LDAPREG].
参考RFC 3383 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（LDAP）に関する考慮事項" [LDAPREG]。
IANA has registered an LDAP Object Identifier for use in this technical specification, according to the following template:
IANAは以下のテンプレートによると、この技術仕様書で使用するLDAPオブジェクト識別子を登録しています：
Subject: Request for LDAP OID Registration
件名：LDAP OIDの登録要求
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Greg Vaudreuil (gregv@ieee.org)
グレッグボードルイ（gregv@ieee.org）
Specification: RFC 4237
仕様：RFC 4237
Author/Change Controller: IESG
著者/変更コントローラ：IESG
Comments:
コメント：
The assigned OID will be used as a base for identifying a number of schema elements defined in this document.
割り当てられたOIDは、この文書で定義されたスキーマ要素の数を識別するためのベースとして使用されるであろう。
IANA has registered the LDAP Descriptors used in this technical specification, as detailed in the following template:
IANAは、次のテンプレートで説明するように、この技術仕様書で使用されるLDAP記述子を登録しています：
Subject: Request for LDAP Descriptor Registration Update
件名：LDAP記述子登録更新要求
Descriptor (vPIM): see comment
記述子（VPIM）：コメントを見ます
Object Identifier: see comment
オブジェクト識別子：コメントを参照してください
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
GregV@ieee.org
ＧれｇＶ＠いえええ。おｒｇ
Usage: see comment
使用方法：コメントを見ます
Specification: RFC 4237
仕様：RFC 4237
Author/Change Controller: IESG
著者/変更コントローラ：IESG
Comments:
コメント：
The following descriptors have been added:
次の記述子が追加されました。
NAME Type OID
-------------- ---- ------------
vPIMUser O IANA-ASSIGNED-OID.1.1
vPIMRfc822Mailbox A IANA-ASSIGNED-OID.2.1
vPIMTelephoneNumber A IANA-ASSIGNED-OID.2.2
vPIMSpokenName A IANA-ASSIGNED-OID.2.3
vPIMSupportedUABehaviors A IANA-ASSIGNED-OID.2.4
vPIMSupportedAudioMediaTypes A IANA-ASSIGNED-OID.2.5
vPIMSupportedMessageContext A IANA-ASSIGNED-OID.2.6
vPIMTextName A IANA-ASSIGNED-OID.2.7
vPIMExtendedAbsenceStatus A IANA-ASSIGNED-OID.2.8
vPIMMaxMessageSize A IANA-ASSIGNED-OID.2.9
vPIMSubMailboxes A IANA-ASSIGNED-OID.2.10
Where Type A is Attribute and Type O is ObjectClass
タイプAは属性であり、タイプOオブジェクトクラスである場合には
[LDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[LDAP]ホッジス、J.とR.モルガン、 "ライトウェイトディレクトリアクセスプロトコル（v3の）：技術仕様"、RFC 3377、2002年9月。
[32KADPCM] Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration", RFC 3802, June 2004.
[32KADPCM]ヴォードルイユ、G.とG.パーソンズ、 "トール品質の音声 - 32キロビット/秒適応差分パルス符号変調（ADPCM）MIMEサブタイプ登録"、RFC 3802、2004年6月。
[CONTEXT] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.
[CONTEXT]バーガー、E.、Candell、E.、エリオット、C.、およびG. Klyne、 "インターネットメールのためのメッセージコンテキスト"、RFC 3458、2003年1月。
[E164] CCITT Recommendation E.164 (1991), Telephone Network and ISDN Operation, Numbering, Routing and Mobile Service - Numbering Plan for the ISDN Era.
[E164] CCITT勧告E.164（1991）、電話網やISDN運用、番号、ルーティングおよびモバイルサービス - ISDN時代の番号計画。
[VPIMV2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[VPIMV2]ヴォードルイユ、G.とG.パーソンズ、 "インターネットメール用の音声プロファイル - バージョン2（VPIMv2）"、RFC 3801、2004年6月。
[LDAPREG] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[LDAPREG] Zeilenga、K.、 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（LDAP）に関する考慮事項"、BCP 64、RFC 3383、2002年9月。
[LDAPAUTH] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000.
[LDAPAUTH]ワール、M.、Alvestrand、H.、ホッジス、J.、およびR.モルガン、 "LDAPのための認証方法"、RFC 2829、2000年5月。
[LDAPMODELS] Zeilenga, K., "LDAP: Directory Information Models" Work in Progress, February 2005.
[LDAPMODELS] Zeilenga、K.、 "LDAP：ディレクトリ情報モデル" 進歩、2005年2月に作業。
Acknowledgements
謝辞
This directory schema builds upon the earlier work of Carl Malamud and Marshall Rose in their TPC.INT remote printing experiment and the work lead by Anne Brown as part of the EMA voice messaging committee's directory effort. Anne Brown has provided important leadership and was a co-author of the original version of this document.
このディレクトリスキーマは、そのTPC.INTリモート印刷実験におけるカール・マラマッドとマーシャルローズの初期の作品とEMAの音声メッセージング委員会のディレクトリの取り組みの一環として、アン・ブラウンの作品リード上に構築されています。アン・ブラウンは、重要なリーダーシップを提供し、このドキュメントのオリジナルバージョンの共著者でした。
Bernhard Elliot, working with the TMIA, has provided most of the organizational impetus to get this project moving, which was a substantial task given the sometimes slow and bureaucratic nature of the voice mail industry and regulatory environment.
ベルンハルト・エリオットは、TMIAと協力して、ボイスメール、業界と規制環境の時々遅いと官僚性質を考えると相当な作業でした。このプロジェクトの移動を、取得するために組織の原動力のほとんどを提供してきました。
Thanks to Dave Dudley and the Messaging Alliance (TMA) for their early work in pioneering a shared directory service for voice messaging and their continuing efforts to apply that work to this effort.
デイヴ・ダドリーとボイスメッセージの共有ディレクトリサービスを開拓における彼らの初期の作品のためのメッセージング・アライアンス（TMA）とその継続的な努力のおかげで、この取り組みにその作業を適用します。
Greg White and Jeff Bouis, both of Lucent Technologies, provided invaluable assistance in reviewing and sanity checking. Countless errors and inconsistencies were corrected with their diligent review.
グレッグ・ホワイトとジェフBouis、ルーセント・テクノロジーの両方が、見直し、正気チェックで非常に貴重な支援を提供します。無数のエラーや不整合が彼らの勤勉なレビューに補正しました。
As chairman of the VPIM working group, Glenn Parsons has provided essential support over the many years this document has been in development.
VPIMワーキンググループの議長として、グレン・パーソンズは、この文書が開発されてきた長年にわたり不可欠なサポートを提供してきました。
Author's Address
著者のアドレス
Please send comments on this document to the VPIM working group mailing list <vpim@ietf.org>.
VPIMワーキンググループのメーリングリスト<vpim@ietf.org>へ、この文書についてのコメントをお送りください。
Gregory M. Vaudreuil Lucent Technologies 9489 Bartgis Ct Frederick, MD 21702
グレゴリーM.ヴォードルイユルーセント・テクノロジーズ9489 BartgisのCtフレデリック、MD 21702
EMail: GregV@ieee.org
メールアドレス：GregV@ieee.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。