RFC4237 日本語訳
4237 Voice Messaging Directory Service. G. Vaudreuil. October 2005. (Format: TXT=26093 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Vaudreuil Request for Comments: 4237 Lucent Technologies Category: Standards Track October 2005
コメントを求めるワーキンググループG.ボードルイの要求をネットワークでつないでください: 4237年のルーセントテクノロジーズカテゴリ: 標準化過程2005年10月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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)ディレクトリサービスにVoice Profileの詳細を明らかにします。 サービスは電話番号が与えられている受取人のEメールアドレスを提供します。 それは任意に受取人の受取人とメディア能力の話された名前を提供します。
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ディレクトリSchemaは、標準化されたディレクトリを使用するというボイスメールユーザー・エクスペリエンスを休養させるために不可欠の追加属性を提供します。 このユーザー・エクスペリエンスはアドレシング時点で、メッセージが意図されるとして提供されるという基本的な保証を提供します。 このドキュメントは2通の以前のドキュメント、アン・ブラウンからの1、およびグレッグ・ボードルイからの1つを結合して、それは声のメッセージング図式をただ一つのワーキンググループ服従と定義します。
Vaudreuil Standards Track [Page 1] RFC 4237 Voice Messaging Directory Service October 2005
ディレクトリサービス2005年10月に通信するボードルイ標準化過程[1ページ]RFC4237声
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
1. 範囲…2 1.1. 目標を設計してください…2 1.2. パフォーマンス規制…2 1.3. スケーリング規制…3 1.4. 信頼性の規制…3 2. VPIMUserディレクトリ図式…3 2.1vPIMTelephoneNumber…4 2.2vPIMRfc822メールボックス…4 2.3vPIMSpokenName…4 2.4vPIMTextName…5 2.5vPIMSupportedAudioMediaTypes…5 2.6vPIMSupportedMessageContext…5 2.7vPIMExtendedAbsenceStatus…6 2.8vPIMSupportedUABehaviors…6 2.9vPIMMaxMessageSize…7 2.10vPIMSubMailboxes…8 3. セキュリティ問題…8 4. IANA問題…9 4.1. オブジェクト識別子…9 4.2. オブジェクト識別子記述子…9 5. 参照…10 5.1. 標準の参照…10 5.2. 有益な参照…10
1. Scope
1. 範囲
1.1. Design Goals
1.1. デザイン目標
The VPIM directory Schema (VPIMDIR) is accessed from outside the enterprise or service provider domain using the recipient's telephone number.
受取人の電話番号を使用することでVPIMディレクトリSchema(VPIMDIR)は企業かサービスプロバイダードメインの外からアクセスされます。
1.2. Performance Constraints
1.2. パフォーマンス規制
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ディレクトリサーバのアイデンティティがいったん知られていると、Eメールアドレス、能力、および話された名前確認情報を検索できます。 この質問がLDAP[LDAP]、接続指向のプロトコルを使用すると予想されます。 プロトコルトランザクションは、質問と検索を実行するために複数のパケット周遊旅行を含んで、メッセージングサービスの最も高い潜在要素であると考えられます。 さらに、確認情報の検索は最大20キロバイト(4キロバイト/秒の5秒)の話された名前セグメントの復帰を必要とするかもしれません。 十分設計されたインターネット接続に関して、1250年のms応答時間が全体のインターネットの上で達成可能であると信じられています。
Vaudreuil Standards Track [Page 2] RFC 4237 Voice Messaging Directory Service October 2005
ディレクトリサービス2005年10月に通信するボードルイ標準化過程[2ページ]RFC4237声
1.3. Scaling Constraints
1.3. スケーリング規制
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相互ドメインアドレスフォームに基づく平坦な名前空間に何千万人もの加入者のためのエントリーを含んでいると予想されます: telephone_number@domain_name 。 大企業には、10万のエントリーがあるかもしれません、大きいサービスプロバイダーは単一領域に何千万ものエントリーを持っているかもしれませんが。 与えられたサービスプロバイダーのネットワークに、ただ一つの場内放送合法化サービスがあると予想されます。 模写で水平なスケーラビリティを含む既存のディレクトリ技術がこの必要性を扱うという必要な潜在要件の中で十分なトランザクションスループットを提供すると信じられています。 このアプリケーションが同様の既存のサービスを超えてディレクトリサーバに課す唯一の基本的で、新しい要件が受取人の話された名前を返す能力です。 下調べは、話された名前のストレージと検索がかなりの潜在を加えないのを示します。 しかしながら、それは記憶容量の必要性に加えるでしょう。
1.4. Reliability Constraints
1.4. 信頼性の規制
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に供給します。 しかしながら、エンドユーザへの潜在要件は、クライアントサイドフェイルオーバーをセカンダリサーバに許可しないで、ディレクトリサーバが高可用性サービスとして実装されるのを必要とするかもしれません。
2. The VPIMUser Directory Schema
2. VPIMUserディレクトリ図式
(IANA-ASSIGNED-OID.1 NAME 'vPIMUser'
SUP 'top'
AUXILIARY
MUST ( vPIMRfc822Mailbox $
vPIMTelephoneNumber )
MAY ( vPIMSpokenName $
vPIMSupportedUABehaviors $
vPIMSupportedAudioMediaTypes $
vPIMSupportedMessageContext $
vPIMTextName $
vPIMExtendedAbsenceStatus $
vPIMMaxMessageSize $
vPIMSubMailboxes ) )
('最高な'補助物がそうしなければならない'vPIMUser'一口(vPIMRfc822Mailbox$vPIMTelephoneNumber)がそうするIANAがOIDを割り当てている.1名(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オブジェクトはダイヤルされた電話番号が意図している受取人に文通されることを確かめることの役に立つ情報を含んでいます。 また、このオブジェクトは送付者による誘導している構成と送付時に配送期待を設定することの役に立つ能力情報とメールボックス状態情報を提供します。
Vaudreuil Standards Track [Page 3] RFC 4237 Voice Messaging Directory Service October 2005
ディレクトリサービス2005年10月に通信するボードルイ標準化過程[3ページ]RFC4237声
2.1. vPIMTelephoneNumber
2.1. vPIMTelephoneNumber
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はどんなサブアドレシング部分も含む電話番号[164E]の完全なE.164フォームです。 通常の検索はこの属性のためにものになるでしょう。
(IANA-ASSIGNED-OID.2.1 NAME 'vPIMTelephoneNumber'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{20} )
(.1が'vPIMTelephoneNumber'平等caseIgnoreMatch構文1.3.6.1.4.1と命名するOIDが割り当てられたIANA.2、.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]でtelephoneNumberとサブアドレス指定情報のサポートとその使用で異なっています。 多くの場合、これらの値は同じになるでしょう。
The telephone number is stored with no parenthesis, spaces, dots, or hyphens. The leading '+' and the '+' delineating the submailbox are required markup.
電話番号は挿入句も、空間も、ドットも、またはハイフンなしで保存されます。 主な'+'と「副-メールボックス」を図で表わす'+'は必要なマーク付けです。
2.2. vPIMRfc822Mailbox
2.2. vPIMRfc822Mailbox
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} )
(.2が'vPIMRfc822Mailbox'平等caseIgnoreIA5Match構文1.3.6.1.4.1と命名するOIDが割り当てられたIANA.2、.1466、.115、.121、.1、.26、256)
2.3. vPIMSpokenName
2.3. vPIMSpokenName
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属性を八重奏ストリングであり、まさに32kbit/s ADPCMでコード化しなければなりません、[32KADPCM]によって定義されるように。vPIMSpokenNameはユーザの声でユーザの話された名前を含むものとします。 セグメントという話された名前の長さは5秒を超えてはいけません。
Vaudreuil Standards Track [Page 4] RFC 4237 Voice Messaging Directory Service October 2005
ディレクトリサービス2005年10月に通信するボードルイ標準化過程[4ページ]RFC4237声
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構文1.3.6の.121の.1の.40の20000のただ一つの.1.4.1.1466.115価値)
2.4. vPIMTextName
2.4. vPIMTextName
The text name is designed to be consistent with the unstructured text name databases used for calling name delivery service of caller 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構文1.3.6の.121の.1の.15の20のただ一つの.1.4.1.1466.115価値)
2.5. vPIMSupportedAudioMediaTypes
2.5. vPIMSupportedAudioMediaTypes
The vPIMSupportedAudioMediaTypes attribute indicates the type(s) of audio encodings that can be received at the address specified in vPIMRfc822Mailbox.
vPIMSupportedAudioMediaTypes属性は、アドレスに受け取ることができるオーディオencodingsのタイプがvPIMRfc822Mailboxで指定したのを示します。
(IANA-ASSIGNED-OID.2.5 NAME 'vPIMSupportedAudioMediaTypes'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
(.5が'vPIMSupportedAudioMediaTypes'平等caseIgnoreIA5Match構文1.3.6.1.4.1と命名するOIDが割り当てられたIANA.2、.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」のどちらかの新しい型名をprependingすることによって、非規格と個人的なコード化タイプを示さなければなりません。
Because ADPCM is a required format, the audio32kadpcm value must be listed if this attribute is present.
ADPCMが必要な形式であるので、この属性が存在しているなら、audio32kadpcm値を記載しなければなりません。
2.6. vPIMSupportedMessageContext
2.6. vPIMSupportedMessageContext
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.
メッセージの文脈は受取人が受け入れそうであるメッセージの文脈に関して指導を送付者に提供します。 メッセージの文脈は与えられた受取人の能力に関する正確な情報よりメディアタイプのリストを提供します。 しかしながら、メディア変換ゲートウェイの増加している役割を考えて、文脈インディケータは「ユニファイド・メッセージング」環境で、より役に立つ指導を送付者に提供します。
Vaudreuil Standards Track [Page 5] RFC 4237 Voice Messaging Directory Service October 2005
ディレクトリサービス2005年10月に通信するボードルイ標準化過程[5ページ]RFC4237声
(IANA-ASSIGNED-OID.2.6 NAME 'vPIMSupportedMessageContext'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
(.6が'vPIMSupportedMessageContext'平等caseIgnoreIA5Match構文1.3.6.1.4.1と命名するOIDが割り当てられたIANA.2、.1466、.115、.121、.1、.26)
This is a multi-value attribute. The set of valid message context values is defined in [CONTEXT].
これはマルチ価値の属性です。 有効なメッセージの文脈値のセットは[CONTEXT]で定義されます。
2.7. vPIMExtendedAbsenceStatus
2.7. vPIMExtendedAbsenceStatus
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構文1.3.6の.115の.121の.1の.26のただ一つの.1.4.1.1466価値)
The three values defined are:
定義された3つの値は以下の通りです。
"Off", "On", "MsgBlocked"
"Off"、“On"、"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.
"Off"は、受取人が拡張不在をサポートしないか、またはそのようなインディケータを設定していないのを示します。 この属性が返されないなら、"Off"はデフォルト条件です。
"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"は、受取人が拡張不在インディケータを設定したのを示します、そして、メールボックスは、現在、入力メッセージを拒絶するために構成されます。 メッセージSHOULD NOT、vPIMExtendedAbsenceStatus属性でこの値を返すなら、受取人に送ってください。
2.8. vPIMSupportedUABehaviors
2.8. vPIMSupportedUABehaviors
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
送付者が、受取人が、多くのオプション機能がそれであるとサポートするかどうか、RFC822ヘッダーで要求するか、または示すことができるのを知るように、インターネット・メールは便宜を与えません。 この属性は受取人によってサポートされるかもしれないVPIMと他のベンダー特有の属性によって任意であると考えられた属性のリストを提供します。 これであるなら、属性はサポートされないで、唯一のそれらは属性です。
Vaudreuil Standards Track [Page 6] RFC 4237 Voice Messaging Directory Service October 2005
ディレクトリサービス2005年10月に通信するボードルイ標準化過程[6ページ]RFC4237声
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.
義務的であるとして記載されていて、VPIMがサポートされると思われます。 明かされていない振舞いはRFC822メッセージで示されるかもしれません。 しかしながら、彼らのサポートの受電方式による保証が全くありません。
(IANA-ASSIGNED-OID.2.8 NAME 'vPIMSupportedUABehaviors'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
(.8が'vPIMSupportedUABehaviors'平等caseIgnoreIA5Match構文1.3.6.1.4.1と命名するOIDが割り当てられたIANA.2、.1466、.115、.121、.1、.26)
The following behaviors are defined:
以下の振舞いは定義されます:
MessageDispositionNotification
MessageSensitivity
MessageImportance
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は、受取人が、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」でこれらの独占拡大値を前に置かなければなりません。
2.9. vPIMMaxMessageSize
2.9. vPIMMaxMessageSize
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はメッセージはバイトが長過ぎるかどうか決定するためにメカニズムを提供しますが、複数のencodings、マルチメディア、または可変ビット伝送速度encodingsがサポートされるとき、それは作曲家のための頼り無いガイドです。
(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構文1.3.6の.115の.121の.1の.27のただ一つの.1.4.1.1466価値)
The attribute indicates the maximum message length in seconds that the receiving mailbox may receive.
属性は受信メールボックスが受信されるかもしれない秒に最大のメッセージ長を示します。
Vaudreuil Standards Track [Page 7] RFC 4237 Voice Messaging Directory Service October 2005
ディレクトリサービス2005年10月に通信するボードルイ標準化過程[7ページ]RFC4237声
2.10. vPIMSubMailboxes
2.10. vPIMSubMailboxes
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} )
(.10が'vPIMSubMailboxes'平等numericStringMatch構文1.3.6.1.4.1と命名するOIDが割り当てられたIANA.2、.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サービスに検索されるかもしれません。
3. Security Considerations
3. セキュリティ問題
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]はこの使用で適用される多くの問題について説明します。 特に、このサービスはディレクトリデータへの非認証されて、公共のアクセスを提供します、そして、そういうものとして、それは凶暴なサーバに質問を向け直して、悪意があるデータを提供する攻撃に被害を受け易いです。
Vaudreuil Standards Track [Page 8] RFC 4237 Voice Messaging Directory Service October 2005
ディレクトリサービス2005年10月に通信するボードルイ標準化過程[8ページ]RFC4237声
4. IANA Considerations
4. IANA問題
Reference RFC 3383 "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)" [LDAPREG].
参照RFC3383「ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のためのインターネット規定番号権威(IANA)問題」[LDAPREG。]
4.1. Object Identifiers
4.1. オブジェクト識別子
IANA has registered an LDAP Object Identifier for use in this technical specification, according to the following template:
以下のテンプレートに従って、IANAはこの技術仕様書に基づく使用のためにLDAP Object Identifierを登録しました:
Subject: Request for LDAP OID Registration
Subject: LDAP OIDには、登録を要求してください。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
Greg Vaudreuil (gregv@ieee.org)
グレッグ・ボードルイ( gregv@ieee.org )
Specification: RFC 4237
仕様: RFC4237
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は、本書では定義された多くの図式要素を特定するのにベースとして使用されるでしょう。
4.2. Object Identifier Descriptors
4.2. オブジェクト識別子記述子
IANA has registered the LDAP Descriptors used in this technical specification, as detailed in the following template:
IANAは以下のテンプレートで詳しく述べられるようにこの技術仕様書で使用されるLDAP Descriptorsを登録しました:
Subject: Request for LDAP Descriptor Registration Update
Subject: LDAP記述子登録最新版を求める要求
Descriptor (vPIM): see comment
記述子(vPIM): コメントを見てください。
Object Identifier: see comment
オブジェクト識別子: コメントを見てください。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
GregV@ieee.org
GregV@ieee.org
Usage: see comment
用法: コメントを見てください。
Specification: RFC 4237
仕様: RFC4237
Author/Change Controller: IESG
コントローラを書くか、または変えてください: IESG
Comments:
コメント:
Vaudreuil Standards Track [Page 9] RFC 4237 Voice Messaging Directory Service October 2005
ディレクトリサービス2005年10月に通信するボードルイ標準化過程[9ページ]RFC4237声
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
名前タイプOID-------------- ---- ------------ vPIMUser O OIDが割り当てられたIANA.1.1vPIMRfc822Mailbox OIDが割り当てられたIANA.2.1vPIMTelephoneNumber OIDが割り当てられたIANA.2.2vPIMSpokenName OIDが割り当てられたIANA.2.3vPIMSupportedUABehaviors OIDが割り当てられたIANA.2.4vPIMSupportedAudioMediaTypes OIDが割り当てられたIANA.2.5vPIMSupportedMessageContext OIDが割り当てられたIANA.2.6vPIMTextName OIDが割り当てられたIANA.2.7vPIMExtendedAbsenceStatus OIDが割り当てられたIANA.2.8vPIMMaxMessageSize OIDが割り当てられたIANA.2.9vPIMSubMailboxes OIDが割り当てられたIANA.2.10
Where Type A is Attribute and Type O is ObjectClass
Type AがAttributeであり、Type OがObjectClassであるところ
5. References
5. 参照
5.1. Normative References
5.1. 引用規格
[LDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[LDAP] ホッジズ、J.、およびR.モーガン、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「技術的な仕様」、RFC3377、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.パーソンズ、「Quality Voiceに料金を課してください--32kbit/s Adaptive Differentialパルスコードの変調(ADPCM)MIME Sub-タイプRegistration」、RFC3802、2004年6月。
[CONTEXT] Burger, E., Candell, E., Eliot, C., and G. Klyne,
"Message Context for Internet Mail", RFC 3458, January
2003.
2003年1月の[文脈]バーガーとE.とCandellとE.とエリオット、C.とG.Klyne、「インターネットメールのためのメッセージの文脈」RFC3458。
[E164] CCITT Recommendation E.164 (1991), Telephone Network and
ISDN Operation, Numbering, Routing and Mobile Service -
Numbering Plan for the ISDN Era.
[164E]のCCITT推薦E.164(1991)、電話網、ISDN操作、付番、ルート設定、およびモバイルサービス--ISDN時代のためのプランに付番します。
5.2. Informative References
5.2. 有益な参照
[VPIMV2] Vaudreuil, G. and G. Parsons, "Voice Profile for
Internet Mail - version 2 (VPIMv2)", RFC 3801, June
2004.
[VPIMV2] ボードルイ、G.、およびG.パーソンズ、「インターネットメールのためにProfileを声に出してください--バージョン2(VPIMv2)」、RFC3801、6月2004日
Vaudreuil Standards Track [Page 10] RFC 4237 Voice Messaging Directory Service October 2005
ディレクトリサービス2005年10月に通信するボードルイ標準化過程[10ページ]RFC4237声
[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.、「インターネットはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のために数の権威(IANA)に問題を割り当てました」、BCP64、RFC3383、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のための認証方法」RFC2829)は2000がそうするかもしれません。
[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.
おかげに、声のメッセージングとそれらの継続する取り組みがそれを当てはまるように共有ディレクトリサービスを開拓することにおける彼らの早めの仕事のためのデーヴ・ダドリーと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.
グレッグ・ホワイトとジェフ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ワーキンググループの議長として、グレン・パーソンズはこのドキュメントの開発中である何年間もにわたっても不可欠のサポートを提供しています。
Vaudreuil Standards Track [Page 11] RFC 4237 Voice Messaging Directory Service October 2005
ディレクトリサービス2005年10月に通信するボードルイ標準化過程[11ページ]RFC4237声
Author's Address
作者のアドレス
Please send comments on this document to the VPIM working group mailing list <vpim@ietf.org>.
VPIMワーキンググループへのこのドキュメントのコメントを list <vpim@ietf.org に郵送させてください、gt。
Gregory M. Vaudreuil Lucent Technologies 9489 Bartgis Ct Frederick, MD 21702
9489年のBartgis ctのグレゴリーM.ボードルイルーセントテクノロジーズのフレディリック、MD 21702
EMail: GregV@ieee.org
メール: GregV@ieee.org
Vaudreuil Standards Track [Page 12] RFC 4237 Voice Messaging Directory Service October 2005
ディレクトリサービス2005年10月に通信するボードルイ標準化過程[12ページ]RFC4237声
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Vaudreuil Standards Track [Page 13]
ボードルイ標準化過程[13ページ]
一覧
スポンサーリンク
