[要約] RFC 4237は、音声メッセージングディレクトリサービスに関する標準化された仕様です。その目的は、音声メッセージングシステムの相互運用性を向上させ、ユーザーが異なるプロバイダ間で音声メッセージを送受信できるようにすることです。
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).
Copyright（c）The Internet Society（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ディレクトリスキーマは、標準化されたディレクトリを使用してボイスメールユーザーエクスペリエンスを再現するための重要な追加属性を提供します。このユーザーエクスペリエンスは、対処時に、メッセージが意図したとおりに配信されることを基本的な保証を提供します。このドキュメントでは、Anne Brownの1つとGreg Vaudreuilからの2つの以前のドキュメントを組み合わせて、音声メッセージングスキーマを単一のワーキンググループ提出に定義します。
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（4kbytes/secondで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.
サービスプロバイダーの名前空間には、VPIM Interdomainアドレスフォームに基づいて、数千万人のサブスクライバーのエントリがフラットネームスペースにあるためのエントリを含めることが期待されています。大企業には1万人のエントリーがある場合がありますが、大規模なサービスプロバイダーは単一のドメインに数千万のエントリを持っている可能性があります。特定のサービスプロバイダーのネットワークには、単一のパブリックアドレス検証サービスがあることが期待されています。複製による水平方向のスケーラビリティを含む既存のディレクトリテクノロジーは、このニーズに対処するために必要なレイテンシ要件内で十分なトランザクションスループットを提供すると考えられています。このアプリケーションがディレクトリサーバーに課す唯一の基本的な新しい要件は、同様の既存のサービスを超えて、受信者の音声名を返す機能です。予備調査によると、話された名前の保管と検索がかなりの遅延を追加しないことが示唆されています。ただし、ストレージ容量が必要になります。
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 ) )
（iana-assigned-of.1 name 'vpimuser' sup 'top' auxiliary（vpimrfc822mailbox $ vpimtelephoneNumber）5月（vpimsporteduabehaviors $ vpimsuabehaviors $ vpimsupportededadiatypes $ vpimsupportedexteps $ vpimsuportedextepes $ vpimsuabehaviors $ Endedabsencestatus $ 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-assigned-of.2.1 name 'vpimtelephoneNumber' equality 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のアドレスを持つ北米の電話番号は、「12145551212 12」として表されます。
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]のThelephoneNumberとは、サブアドレスリング情報と音声メッセージングアドレスとしての使用をサポートすることが異なります。ほとんどの場合、これらの値は同じになります。
The telephone number is stored with no parenthesis, spaces, dots, or hyphens. The leading '+' and the '+' delineating the submailbox are required markup.
電話番号は、括弧、スペース、ドット、またはハイフンなしで保管されます。主要な ''と '' submailboxを描写する必要があります。
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属性と区別するための明確な属性として定義されます。VPIMRFC822MAILBOXをRFC822Mailboxのサブタイプとして定義することは望ましいことですが、一部のディレクトリ実装はサブタイピングをサポートしていないため、ここでは完全に新しい属性として定義されます。
(IANA-ASSIGNED-OID.2.2 NAME 'vPIMRfc822Mailbox' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
（iana-assigned-of.2.2 name 'vpimrfc822mailbox' equality 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属性はOctet文字列であり、[32KADPCM]で定義されているように、32 KBIT/s 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-assigned-of.2.3 name 'vpimspokenname' equality octetsstringmatch構文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-assigned-of.2.4 name 'vpimtextname' equality caseignorematch構文1.3.6.1.4.1.146.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.
vpimsupportededaumediatypes属性は、vpimrfc822mailboxで指定されたアドレスで受信できるオーディオエンコーディングのタイプを示します。
(IANA-ASSIGNED-OID.2.5 NAME 'vPIMSupportedAudioMediaTypes' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
（iana-assigned-of.2.5 name 'vpimsupportedaudiomediatypes' equality caseignoreia5match Syntax 1.3.6.1.1.1466.115.121.1.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-assigned-of.2.6 name 'vpimsuptedmessagecontext' equality caseignoreia5match構文1.3.6.1.4.1.1466.115.121.1.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-assigned-of.2.7 name 'vpimextendedabsencestatus' equality caseignoreia5match構文1.3.6.1.4.1.146.115.121.1.26単一値）
The three values defined are:
定義された3つの値は次のとおりです。
"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.
「On」は、受信者が延長された不在インジケーターを設定したことを示しますが、メールボックスは不特定の時期にレビューのメッセージを受け入れています。
"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」は、受信者が拡張不在インジケーターを設定していることを示し、現在、メールボックスが着信メッセージを拒否するように構成されていることを示しています。この値がVPIMEXTEDEDABSENCESTATUS属性で返される場合、メッセージを受信者に送信しないでください。
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-assigned-of.2.8 name 'vpimsuporteduabehaviors' equality caseignoreia5match Syntax 1.3.6.1.4.1.1466.115.121.1.1.26）
The following behaviors are defined:
次の動作が定義されています。
MessageDispositionNotification MessageSensitivity MessageImportance
MESSAGEDISPOSITION -NOTIFICATION MESSUASESITIVITION MESSAGEIMPORTANCE
The presence of the MessageDispositionNotification value indicates that the recipient will send an MDN in response to an MDN request.
MESSAGEDISPOSITION -NOTIFICATION値の存在は、受信者がMDN要求に応じてMDNを送信することを示しています。
MessageSensitivity indicates that the recipient fully supports the sensitivity indication as defined in VPIM [VPIMV2].
メッセージ感度は、レシピエントがVPIM [VPIMV2]で定義されているように感度の表示を完全にサポートしていることを示しています。
MessageImportance indicates that the recipient fully supports the importance indication as defined in VPIM [VPIMV2].
MessageImportanceは、VPIM [VPIMV2]で定義されているように、受信者が重要な表示を完全にサポートしていることを示しています。
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-assigned-of.2.9 name 'vpimmaxmessagesize' equality integermatch構文1.3.6.1.4.1.146.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-assigned-of.2.10 name 'vpimsubmailboxes' equality 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) 多くの国では、特定の種類の記述情報（テキスト名など）の開示を禁止するプライバシー法または規制があります。したがって、サーバーの実装者は、DIT構造ルールと名前フォーム[LDAPModels]をサポートすることをお勧めします。管理者は、これらのメカニズム、アクセス制御、およびその他の管理コントロールを使用することをお勧めします。これらは、エントリの名前を付けるときに機密情報を含む属性の使用を制限するために利用できる場合があります。
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]は、この使用に適用される多くの考慮事項について説明しています。特に、このサービスは、ディレクトリデータへの無慈悲でパブリックなアクセスを提供するため、クエリをRogueサーバーにリダイレクトし、悪意のあるデータを提供する攻撃に対して脆弱です。
Reference RFC 3383 "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)" [LDAPREG].
参照RFC 3383 "LightWeight Directory Access Protocol（LDAP）" [LDAPREG]について、インターネットが割り当てられた数字の権限（IANA）の考慮事項。
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:
詳細については、連絡先への個人およびメールアドレス：
Greg Vaudreuil (gregv@ieee.org)
Greg Vaudreuil（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:
詳細については、連絡先への個人およびメールアドレス：
GregV@ieee.org
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] Hodges、J。およびR. Morgan、「Lightweight Directory Access Protocol（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] Vaudreuil、G。およびG. Parsons、「Toll Quality Voice -32 Kbit/s適応微分パルスコード変調（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] Burger、E.、Candell、E.、Eliot、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] Vaudreuil、G。およびG. Parsons、「インターネットメールの音声プロファイル -バージョン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。、「Lightweight Directory Access Protocol（LDAP）のインターネット割り当てされた数字権（IANA）の考慮事項」、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] Wahl、M.、Alvestrand、H.、Hodges、J。、およびR. Morgan、「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.
このディレクトリスキーマは、Carl MalamudとMarshall Roseの以前の作業に基づいて構築され、TPC.intリモート印刷実験とEMA Voice Messaging委員会のディレクトリの取り組みの一部としてAnne Brownがリードしています。アン・ブラウンは重要なリーダーシップを提供し、このドキュメントのオリジナルバージョンの共著者でした。
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と協力しているBernhard Elliotは、このプロジェクトを動かすためにほとんどの組織的な推進力を提供しました。これは、ボイスメール業界と規制環境の時々遅くて官僚的な性質を考えると、かなりの課題でした。
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.
Dave DudleyとThe Messaging Alliance（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.
Lucent Technologiesの両方のGreg WhiteとJeff 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
Gregory M. Vaudreuil Lucent Technologies 9489 Bartgis CT Frederick、MD 21702
EMail: GregV@ieee.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.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エディター機能の資金は現在、インターネット協会によって提供されています。