RFC4024 日本語訳

Network Working Group                                         G. Parsons
Request for Comments: 4024                               Nortel Networks
Category: Informational                                      J. Maruszak
                                                               July 2005

教区牧師がコメントのために要求するワーキンググループG.をネットワークでつないでください: 4024 ノーテルはカテゴリをネットワークでつなぎます: 情報のJ.Maruszak2005年7月

                   Voice Messaging Client Behaviour

声のメッセージングクライアントのふるまい

Status of This Memo

このメモの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   This document defines the expected behaviour of a client to various
   aspects of a Voice Profile for Internet Mail (VPIM) message or any
   voice and/or fax message.

このドキュメントはどんなインターネットメール(VPIM)メッセージや声、そして/または、ファックス通信のためにもクライアントの予想されたふるまいをVoice Profileの種々相と定義します。

Table of Contents

目次

   1.  Introduction..................................................  2
   2.  Conventions Used in This Document.............................  2
   3.  Message Icon..................................................  3
       3.1.  Proposed Mechanism......................................  3
   4.  Sender's Number Column........................................  3
       4.1.  Proposed Mechanism......................................  4
   5.  Message Size..................................................  4
       5.1.  Proposed Mechanism......................................  4
   6.  Media Viewer..................................................  5
       6.1.  Proposed Mechanism......................................  6
   7.  Mark Message as Read..........................................  6
       7.1.  Proposed Mechanism......................................  6
   8.  Security Considerations.......................................  7
   9.  Informative References........................................  7
   10. Acknowledgments...............................................  8

1. 序論… 2 2. このドキュメントで中古のコンベンション… 2 3. メッセージアイコン… 3 3.1. メカニズムを提案します… 3 4. 送付者の数のコラム… 3 4.1. メカニズムを提案します… 4 5. メッセージサイズ… 4 5.1. メカニズムを提案します… 4 6. メディアビューアー… 5 6.1. メカニズムを提案します… 6 7. 読まれるようにメッセージをマークしてください… 6 7.1. メカニズムを提案します… 6 8. セキュリティ問題… 7 9. 有益な参照… 7 10. 承認… 8

Parsons & Maruszak           Informational                      [Page 1]

RFC 4024            Voice Messaging Client Behaviour           July 2005

クライアントふるまい2005年7月に通信するパーソンズとMaruszakの情報[1ページ]のRFC4024声

1.  Introduction

1. 序論

   As Internet messaging evolves into unified messaging, the term
   "e-mail" no longer refers to text-only messages.  Today's "e-mail"
   are often multi-media.  That is, they can have numerous non-text
   parts.  These parts can be attachments or can contain voice and/or
   fax.

メッセージングがユニファイド・メッセージングに発展するインターネットには、「メール」という用語はもうテキストのみメッセージを呼びません。 しばしば今日の「メール」はマルチメディアです。 すなわち、彼らは多数の非テキスト部分を持つことができます。 これらの部品は、付属であることができるか声、そして/または、ファックスを含むことができます。

   Each of voice, fax, and text have their own distinct characteristics,
   which are intuitive to the user.  For example, each of these message
   types require a different media viewer (text editor for text, audio
   player for voice, and image viewer for fax), and the dimensions of
   message size are also different for all three (kilobytes for text,
   seconds for voice, and pages for fax).  As a result, a message that
   includes more than one of these in its parts is termed a mixed media
   message.

それぞれの声、ファックス、およびテキストには、それら自身のはっきりした性格があります。(ユーザにとって、はっきりした性格は直感的です)。 例えば、これらのメッセージタイプ各人は異なったメディアビューアー(テキストのためのテキストエディタ、声のためのオーディオプレーヤー、およびファックスのための画像ビューワ)を必要とします、そして、また、すべての3(テキストのためのキロバイト、声のための秒、およびファックスのためのページ)において、メッセージサイズの次元も異なっています。 その結果、部品にこれらの1つ以上を含んでいるメッセージは混合媒体メッセージと呼ばれます。

   How the messaging client responds to, and acts on these differences
   is termed "Client Behaviour".  This is dependent on the concept of
   "Message-Context" [2] (previously called primary content), which
   defines whether the message is a voice mail, fax, or text message.
   The client can utilize this header to determine the appropriate
   client behaviour for a particular message.

メッセージングクライアントがどうこれらの違いを応じて、影響するかは「クライアントのふるまい」と呼ばれます。 これは「メッセージの文脈」[2](以前に、プライマリ内容と呼ばれます)の概念に依存しています。概念はメッセージがボイスメール、ファックス、またはテキストメッセージであるかを定義します。 クライアントは、特定のメッセージのための適切なクライアントのふるまいを決定するのにこのヘッダーを利用できます。

   Traditionally, a messaging "client" referred to some sort of visual
   interface (or GUI - graphical user interface) that was presented on
   the users computer.  However, as messaging evolves to unified
   communications the actual form of the messaging client is expected to
   change.  Today's email can often be viewed on wireless devices with
   very limited screens or even "viewed" over a telephone (i.e.,
   listening to email as you would listen to voice mail through a TUI -
   telset user interface).

または、伝統的に、通信している「クライアント」がある種の視覚インタフェースを示した、(GUI--グラフィカルユーザーインターフェース) それはユーザコンピュータで提示されました。 しかしながら、メッセージングが統一されたコミュニケーションに発展するとき、メッセージングクライアントの実際のフォームが変化すると予想されます。 しばしば今日のメールをワイヤレス機器の上に非常に限られたスクリーンで見るか、または電話の上で「見ることさえできる」(すなわち、あなたがTUIを通してボイスメールを聞くだろう、そうしながら、メールを聞きます--telsetユーザーインタフェース)。

   The intent of this document is to be general and refer to all types
   of messaging clients, as the user's expectation of behaviour based on
   the type of message is not expected to change.  However, some of the
   following concepts may tend towards the more common GUI client.

このドキュメントの意図は、一般的であり、すべてのタイプのメッセージングクライアントについて言及することです、メッセージのタイプに基づいたふるまいへのユーザの期待が変えないと予想されるとき。 しかしながら、以下の概念のいくつかが、より一般的なGUIクライアントの傾向があるかもしれません。

2.  Conventions Used in This Document

2. 本書では使用されるコンベンション

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [4].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC-2119[4]で説明されるように本書では解釈されることであるべきですか?

Parsons & Maruszak           Informational                      [Page 2]

RFC 4024            Voice Messaging Client Behaviour           July 2005

クライアントふるまい2005年7月に通信するパーソンズとMaruszakの情報[2ページ]のRFC4024声

3.  Message Icon

3. メッセージアイコン

   The preferred method to distinguish between voice, fax, and text
   messages on a GUI client is with a visual cue, or icon.  A similar
   voice prompt or "earcon" would be used for TUI clients.

GUIクライアントに関する声、ファックス、およびテキスト・メッセージを見分ける適した方法が視覚的な合図、またはアイコンであります。 同様の声のプロンプトか"earcon"がTUIクライアントに使用されるでしょう。

   As it is possible for the message to contain more than one media
   type, the icon should describe the primary message content, as
   defined by the "Message-Context" header.  Obvious choices for the
   icon/message pairs would be a telephone for a voice message, a fax
   machine for a fax message, and an envelope for a text mail message.
   Similarly obvious for the earcons would be short spoken prompts like
   "voice message".

1つ以上のメディアタイプを含むメッセージに、それが可能であるので、アイコンはプライマリメッセージ内容について説明するはずです、「メッセージの文脈」ヘッダーによって定義されるように。 アイコン/メッセージ組当然の選択は、音声メールのための電話と、ファックス通信のためのファックス装置と、テキストメール・メッセージのための封筒でしょう。 earconsには同様に明白であるのは、「音声メール」のように短い話されたプロンプトでしょう。

   This could be taken a step further, and have the GUI icon change to
   indicate that the message has been read as is currently done in some
   email clients (others do not change the icon but merely bold the
   message in the message list to indicate it is unread).  For example,
   a telephone with the receiver off-hook could indicate that the voice
   message has been played.  A fax machine with paper at the bottom, as
   opposed to the top, would show that the fax had been viewed.
   Finally, an open envelope indicates that a text message has been
   read.

これで、さらに前進して、GUIアイコンは、メッセージが現在何人かのメールクライアントで行われる読書であることを示すために変化するかもしれません(どんな変化にもアイコンをしませんが、他のものはそれが読まれていないのを示すメッセージリストのメッセージを単にボールドにします)。 例えば、受信機がフックであることでの電話は、音声メールがプレーされたのを示すかもしれません。 先端と対照的に紙が下部にあるファックス装置は、ファックスを見てあったのを示すでしょう。 最終的に、開いている封筒は、テキストメッセージを読んであるのを示します。

3.1.  Proposed Mechanism

3.1. 提案されたメカニズム

   As the choice of icon is determined by the primary message type, the
   client should obtain this information from the "Message-Context "
   message header.  This header is defined in [2].

アイコンの選択がプライマリメッセージタイプによって決定されるとき、クライアントは「メッセージ文脈」メッセージヘッダーからこの情報を得るべきです。 このヘッダーは[2]で定義されます。

4.  Sender's Number Column

4. 送付者の数のコラム

   As is the case with most email GUI clients today, important message
   information is organized into columns when presented to the user in a
   the summary message list.  TUIs often present even briefer summaries
   to the user at the beginning of the session.  Typical columns in the
   GUI client include the message subject, and the date the message was
   received.

ユーザへのaの概要メッセージリストが提示されるとき、今日ほとんどのメールGUIクライアントに関してそうであるように、重要なメッセージ情報はコラムに組織化されます。 TUIsはセッションの始めにしばしばさらに簡潔な概要をユーザに提示します。 GUIクライアントの典型的なコラムはメッセージ対象、およびメッセージが受け取られた日付を含んでいます。

   Another important piece of information for the user is the origin of
   the message.  For a voice or fax message, the origin is typically a
   telephone or fax machine respectively, each of which has an
   associated telephone number.  This telephone number is critical to
   the user if they wish to return the call.  This should be presented
   accurately to the user (without making it an email address).

もう1つのユーザにとって、重要な情報がメッセージの発生源です。 声かファックス通信に関しては、通常、発生源は、それぞれそれのそれぞれには関連電話番号がある電話かファックス装置です。 彼らが呼び出しを返したいなら、ユーザにとって、この電話番号は重要です。 これは正確にユーザ(それをEメールアドレスにすることのない)に提示されるべきです。

Parsons & Maruszak           Informational                      [Page 3]

RFC 4024            Voice Messaging Client Behaviour           July 2005

クライアントふるまい2005年7月に通信するパーソンズとMaruszakの情報[3ページ]のRFC4024声

4.1.  Proposed Mechanism

4.1. 提案されたメカニズム

   Instead of forcing the telephone number into an email address, a new
   Internet message header can be used to hold the originating telephone
   number [3].  If the message is indicated as being a voice or fax
   message per [2], the client should extract the number, and display it
   to the user in a separate column.  As this header is defined to only
   hold the digits of the telephone number, it is left to the client to
   add any separating characters (e.g., "-").

Eメールアドレスに電話番号を力づくで押すことの代わりに、起因している電話番号[3]を保持するのに新しいインターネットメッセージヘッダーを使用できます。 メッセージが1[2]あたり声か1つのファックス通信であるとして示されるなら、クライアントは、別欄にユーザに数を抽出して、それを表示するべきです。 このヘッダーが電話番号のケタを保持するだけであるために定義されるとき、それがどんな区切り文字(例えば、「-」)も加えるのがクライアントに残されます。

5.  Message Size

5. メッセージサイズ

   In the cases of large attachments, small clients (e.g., PDA) and slow
   links (e.g., wireless) there is also a need for the client to see the
   length of the message in a suitable format before opening it.

また、大きい付属、小さいクライアント(例えば、PDA)、および遅いリンク(例えば、ワイヤレス)の場合には、それを開く前にクライアントが適当な形式のメッセージの長さを見る必要があります。

   Currently, message size is normally given in kilobytes (kB).  This
   is sufficient for plain text messages, but while it may give a hint
   as to how good the compression algorithm is, kB is not very useful in
   knowing the size of a voice and/or fax message.  Instead, the size
   should give an indication of the length of the message, i.e., the
   duration (in seconds) of a voice message, and the number of pages of
   a fax.  Again, the message may contain multiple types, so the size
   displayed should be that of the primary content type, per [2].

現在、キロバイト(kB)で通常、メッセージサイズを与えます。 これはプレーンテキストメッセージに十分ですが、圧縮アルゴリズムがどれくらい良いかに関してちょっとほのめかすかもしれませんが、kBは声、そして/または、ファックス通信のサイズを知る際にそれほど役に立ちません。 代わりに、サイズはすなわち、メッセージの長さ、音声メールの持続時間(秒の)、およびファックスのページ数のしるしを与えるべきです。 一方、メッセージが複数のタイプを含むかもしれないので、表示されたサイズはプライマリcontent typeのものであるべきです、[2]単位で。

5.1.  Proposed Mechanisms

5.1. 提案されたメカニズム

   There are three suggested methods to relay this information, of them,
   the first method is favored:

この情報をリレーする3つの提案されたメソッドがあって、それらでは、最初のメソッドは支持されます:

5.1.1.  MIME Header Content-Duration as described in RFC 2424 [5]

5.1.1. RFC2424で説明されるMIME Header Content-持続時間[5]

   For voice messages, the Content-Duration field of the main audio/*
   body part (as indicated by content-disposition per [1]) should be
   displayed as the length of the message.  If there are several audio
   parts, an implementation may display the message size as an aggregate
   of the length of each.

音声メールに関して、主なオーディオ/*ボディーのContent-持続時間野原は離れています。(1[1])あたりの内容気質によって示されるように、メッセージの長さとして表示するべきです。 数個のオーディオの部品があれば、実装はそれぞれの長さの集合としてメッセージサイズを表示するかもしれません。

   For fax messages a new MIME Header, Content-Page-Length, could be
   defined, similar to Content-Duration with the exception that number
   of pages would be specified, rather than number of seconds.  (e.g.,
   Content-Page-Length:3).  This would be created at origination.

ファックス通信に関しては、新しいMIME Header(Contentページの長さ)を定義できました、秒数よりむしろ指定されていて、ページ数がそうする例外についてContent-持続時間と同様です。 (例えば、内容ページ長: 3)。 これは創作で作成されるでしょう。

Parsons & Maruszak           Informational                      [Page 4]

RFC 4024            Voice Messaging Client Behaviour           July 2005

クライアントふるまい2005年7月に通信するパーソンズとMaruszakの情報[4ページ]のRFC4024声

5.1.2.  Message length indicated as a parameter of an Existing
        RFC 2045 [7] Content-Type Header Field

5.1.2. メッセージ長はExisting RFC2045のパラメタとして[7] コンテントタイプHeader Fieldを示しました。

   This would be created at the source.  This proposed method would
   allow the message length to be passed to the client by default in
   IMAP.  Again the client would have to choose between the main voice
   message length or an aggregate message length for display.

これはソースで作成されるでしょう。 この提案されたメソッドは、メッセージ長がデフォルトでIMAPでクライアントに渡されるのを許容するでしょう。 一方、クライアントはディスプレイのために主な声のメッセージ長か集合メッセージ長を選ばなければならないでしょう。

   Content-Type Header Field example:

コンテントタイプHeader Fieldの例:

   Content-Type=audio/*; length=50
   Content-Type=image/tiff; pages=3

コンテントタイプはオーディオ/*と等しいです。 長さは50コンテントタイプ=イメージ/いさかいと等しいです。 ページ=3

5.1.3.  Message length indicated as part of an existing RFC 2822 [9]
        Header Field

5.1.3. メッセージ長は既存のRFC2822の一部として[9] ヘッダーFieldを示しました。

   This field would be created at the source and may include message
   length information, but because it is part of the message headers, it
   could also be amended on reception (by a local process).  This method
   would allow the message length to be passed to any client by default
   and not require any client modification.  If used, this field would
   indicate the aggregate length of all attachments.

この分野は、ソースで作成されて、メッセージ長情報を含むかもしれませんが、それがメッセージヘッダーの一部であるので、また、レセプション(地方のプロセスによる)でそれを修正できました。 このメソッドで、メッセージ長は、デフォルトでどんなクライアントにも渡されて、少しのクライアント変更も必要としないでしょう。 使用されるなら、この分野はすべての付属の集合長さを示すでしょう。

   The advantage of this mechanism is that no new headers are required
   and it works with existing clients.  The downside is that it
   overloads the subject field.

このメカニズムの利点はどんな新しいヘッダーも必要でなく、既存のクライアントと共に働いているということです。 下落傾向は対象の野原を積みすぎるということです。

   Subject Header Field example:

対象のHeader Fieldの例:

   Subject=Voice Message (0:04)
   Subject=Fax Message (3p)
   Subject=Voice Message (0:14) with Fax (1p)

対象の=音声メール(0:04)対象=ファックス通信(3p)対象はファックスで音声メール(0:14)と等しいです。(1p)

6.  Media Viewer

6. メディアビューアー

   When a message is initially opened, the client should, by default,
   open the proper media viewer to display the primary message content.
   That is, an audio player for voice messages, an image viewer for fax,
   and a text editor for text messages.  Note that on a TUI, the viewer
   would render the media to sound (which would have varying effect
   depending on the media and available process).

メッセージが初めは開かれるとき、クライアントは、プライマリメッセージ内容を表示するためにデフォルトで適切なメディアビューアーを開けるべきです。 すなわち、音声メールのためのオーディオプレーヤー、ファックスのための画像ビューワ、およびテキスト・メッセージのためのテキストエディタ。 TUIでは、ビューアーが音(メディアと利用可能なプロセスに頼る異なった効果を持っている)にメディアを提供することに注意してください。

   Where there is more than one body part, obviously the appropriate
   viewer should be used depending on which body part the user has
   selected.

1つ以上の身体の部分があるところでは、ユーザが選択したどの身体の部分によって、明らかに、適切なビューアーは使用されるべきです。

Parsons & Maruszak           Informational                      [Page 5]

RFC 4024            Voice Messaging Client Behaviour           July 2005

クライアントふるまい2005年7月に通信するパーソンズとMaruszakの情報[5ページ]のRFC4024声

   In the case where several viewers are available for a single media
   type, the user should be prompted to select the desired viewer on the
   first occasion that the message type is encountered.  That viewer
   should then become the default viewer for that media type.  The user
   should have the ability to change the default viewer for a media type
   at any time.

数人のビューアーが単独のメディアタイプに利用可能である、ユーザが機会のあり次第必要なビューアーを選ぶようにうながされるべきである場合では、メッセージがタイプするのは遭遇します。 そして、そのビューアーはそのメディアタイプのためのデフォルトビューアーになるべきです。 ユーザには、いつでもメディアタイプのためにデフォルトビューアーを変える能力があるべきです。

   Note that it is possible that the media viewer may not be part of the
   client or local to the host of the client.  For example, a user could
   select to play a voice message from a GUI and the message is played
   over a telephone (perhaps because the user has no desktop speakers).
   Additionally, a user listening to a unified messaging inbox over a
   TUI could chose to print a particular message to a nearby fax
   machine.

メディアビューアーがクライアントのホストにとってのクライアントか地方の部分でないかもしれない可能に注意してください。 例えば、ユーザはGUIからの音声メールをプレーに選択できました、そして、メッセージは電話の上でプレーされます(恐らくユーザにはデスクトップスピーカーが全くいないので)。 さらに、TUIの上でユニファイド・メッセージング受信トレイを聞いているユーザは選ぶことができました。近くのファックス装置に特定のメッセージを印刷するのを選びました。

6.1.  Proposed Mechanism

6.1. 提案されたメカニズム

   As mentioned, the default viewer displayed to the user should be the
   appropriate one for the primary message type.  The client is able to
   determine the primary message type from the "Message-Context" message
   header per [2].

言及されるように、ユーザに表示されたデフォルトビューアーはプライマリメッセージタイプのための適切なものであるべきです。 クライアントは1[2]あたりの「メッセージの文脈」メッセージヘッダーからプライマリメッセージタイプを決定できます。

7.  Mark Message as Read

7. 読まれるようにメッセージをマークしてください。

   Obviously, the user must be able to know which messages they have
   read, and which are unread.  This feature would also control the
   message icon or earcon as mentioned in section 1.

明らかに、ユーザはどのメッセージを読むか、そして、どれが読まれていないかを知ることができなければなりません。 また、この特徴はセクション1で言及されるようにメッセージのアイコンかearconを制御するでしょう。

   With the proliferation of voice and fax messages, clients should only
   indicate that these messages are read when the primary body part has
   been read.  For example, a voice message should not be indicated as
   read until the audio part has been played.  The default is currently
   to mark a message read, when the first body part (typically text) is
   viewed.

声とファックス通信の増殖で、クライアントは、プライマリ身体の部分を読んであるとき、これらのメッセージが読まれるのを示すだけであるべきです。 例えば、オーディオ役割が演じられるまで読まれるように音声メールを示すべきではありません。 デフォルトは現在、最初の身体の部分(通常テキスト)が見られるとき読まれたメッセージをマークすることです。

7.1.  Proposed Mechanism

7.1. 提案されたメカニズム

   Implementation of this feature on most clients is a local issue.

ほとんどのクライアントに関するこの特徴の実装はローカルの問題です。

   For example, in the case of IMAP4 [6], these clients should only set
   the \SEEN flag after the first attachment of the primary content type
   has been opened.  That is, if the message context is voice message,
   the \SEEN flag would be set after the primary voice message
   (indicated by content-disposition [1] or content-criticality [8]) is
   opened.

例えば、IMAP4[6]の場合では、プライマリcontent typeの最初の付属が開かれた後にこれらのクライアントはSEENが旗を揚げさせる\を設定するだけであるべきです。 SEENが旗を揚げさせる\はすなわち、メッセージの文脈が音声メールであるなら、プライマリ音声メールの後に設定されるでしょう。(満足している気質[1]か内容臨界で、[8])が開かれるのを示しました。

Parsons & Maruszak           Informational                      [Page 6]

RFC 4024            Voice Messaging Client Behaviour           July 2005

クライアントふるまい2005年7月に通信するパーソンズとMaruszakの情報[6ページ]のRFC4024声

8.  Security Considerations

8. セキュリティ問題

   The desirable client behaviours described here are intended to
   provide the user with a better client experience.  However,
   supporting the proposed behaviours described in this document does
   not make a client immune from the risks of being a mail client.  That
   is, the client is not responsible for the format of the message
   received, it only interprets.  As a result, messages could be spoofed
   or masqueraded to look like a message they are not to elicit a
   desired client behaviour.  This could be used to fool the end user,
   for example, into thinking a message was a voice message (because of
   the icon) when it was not.

ここで説明された望ましいクライアントのふるまいが、より良いクライアント経験をユーザに提供することを意図します。 しかしながら、本書では説明された提案されたふるまいをサポートするのに、クライアントはメールクライアントであるリスクから免疫があるようになりません。 すなわち、クライアントは受け取られたメッセージの形式に責任がない、それが解釈するだけです。 その結果、メッセージは、必要なクライアントのふるまいを引き出すことになっていないというメッセージに似るように偽造されたか仮装できました。 それが使用されなかったとき、例えば、メッセージが音声メール(アイコンによる)であったと思うのにエンドユーザをだますのにこれを使用できました。

9.  Informative References

9. 有益な参照

   [1]  Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail -
        version 2 (VPIMv2)", RFC 3801, June 2004.

[1] ボードルイ、G.、およびG.パーソンズ、「インターネットメールのためにProfileを声に出してください--バージョン2(VPIMv2)」、RFC3801、6月2004日

   [2]  Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
        Context for Internet Mail", RFC 3458, January 2003.

2003年1月の[2] バーガーとE.とCandellとE.とエリオット、C.とG.Klyne、「インターネットメールのためのメッセージの文脈」RFC3458。

   [3]  Parsons, G. and J. Maruszak, "Calling Line Identification for
        Voice Mail Messages", RFC 3939, December 2004.

[3] パーソンズとG.とJ.Maruszak、「線をボイスメールメッセージのための識別と呼びます」、RFC3939、2004年12月。

   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [5]  Vaudreuil, G. and G. Parsons, "Content Duration MIME Header
        Definition", RFC 3803, June 2004.

[5] ボードルイとG.とG.パーソンズ、「満足している持続時間MIMEヘッダー定義」、RFC3803、2004年6月。

   [6]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
        RFC 3501, March 2003.

[6] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」

   [7]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, November 1996.

解放された[7]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。

   [8]  Burger, E., "Critical Content Multi-purpose Internet Mail
        Extensions (MIME) Parameter", RFC 3459, January 2003.

[8] バーガー、E.、「重要な満足している多目的のインターネットメール拡大(MIME)パラメタ」、RFC3459、2003年1月。

   [9]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.

[9] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。

   [10] Parsons, G., "IMAP Voice Extensions", Work in Progress, June
        1999.

[10] G.、「IMAP声の拡張子」という教区牧師は進歩、1999年6月に働いています。

Parsons & Maruszak           Informational                      [Page 7]

RFC 4024            Voice Messaging Client Behaviour           July 2005

クライアントふるまい2005年7月に通信するパーソンズとMaruszakの情報[7ページ]のRFC4024声

10.  Acknowledgments

10. 承認

   This work was inspired by the discussion of "Proposed Mechanisms" for
   IMAP that were detailed in a since expired work in progress entitled
   "IMAP Voice Extensions" [10].  The authors would like to acknowledge
   all those who contributed to that document.  In addition, Cheryl
   Kinden, Derrick Dunne, and Jason Collins assisted in the editing of
   previous revisions of this document.

この仕事は満期の処理中の作業が「IMAP声の拡張子」に[10]の権利を与えたのでaで詳細であったIMAPのために「提案されたメカニズム」の議論で奮い立たせられました。 作者はそのドキュメントに貢献したすべての人を承認したがっています。 さらに、シェリルきんでん、Derrickダン、およびジェイソン・コリンズはこのドキュメントの前の改正の編集を助けました。

Author's Addresses

作者のアドレス

   Glenn Parsons
   Nortel Networks
   P.O. Box 3511, Station C
   Ottawa, ON  K1Y 4H7
   Canada
   Phone: +1-613-763-7582
   Fax: +1-613-967-5060
   EMail: gparsons@nortel.com

グレンノーテル教区牧師は私書箱3511、駅のCオタワをK1Y 4H7カナダ電話にネットワークでつなぎます: +1-613-763-7582 Fax: +1-613-967-5060 メールしてください: gparsons@nortel.com

   Janusz Maruszak
   Phone: +1-416-885-0221
   EMail: jjmaruszak@sympatico.ca

ヤヌシMaruszakは以下に電話をします。 +1-416-885-0221 メールしてください: jjmaruszak@sympatico.ca

Parsons & Maruszak           Informational                      [Page 8]

RFC 4024            Voice Messaging Client Behaviour           July 2005

クライアントふるまい2005年7月に通信するパーソンズとMaruszakの情報[8ページ]のRFC4024声

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機能のための基金は現在、インターネット協会によって提供されます。

Parsons & Maruszak           Informational                      [Page 9]

パーソンズとMaruszak情報です。[9ページ]