RFC 3458

RFC 3458

Message Context for Internet Mail Internetmailmessage文脈

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.

Abstract

   This memo describes a new RFC 2822 message header, "Message-Context".
   This header provides information about the context and presentation
   characteristics of a message.
   A receiving user agent (UA) may use this information as a hint to
   optimally present the message.
*Table of Contents
   1. Introduction....................................................2
   2. Conventions used in this document...............................3
   3. Motivation......................................................3
   4. Functional Requirements.........................................5
   5. Determining the Message Context.................................6
   6. Message-Context Reference Field.................................7
     6.1. Message-Context Syntax......................................7
     6.2. message-context-class Syntax................................7
       6.2.1. voice-message...........................................8
       6.2.2. fax-message.............................................8
       6.2.3. pager-message...........................................8
       6.2.4. multimedia-message......................................8
       6.2.5. text-message............................................8
       6.2.6. none....................................................8
   7. Security Considerations.........................................9
   8. IANA Considerations.............................................9
     8.1. Message Content Type Registrations..........................9
     8.2. Registration Template......................................10
     8.3. Message-Context Registration...............................11
   9. APPENDIX: Some messaging scenarios.............................12
     9.1. Internet e-mail............................................12
     9.2. Pager service..............................................12
     9.3. Facsimile..................................................13
     9.4. Voice mail.................................................14
     9.5. Multimedia message.........................................14
   10. References....................................................15
     10.1 Normative References.......................................15
     10.2 Informative References.....................................15
   11. Acknowledgments...............................................15
   12. Authors' Addresses............................................16
   13. Full Copyright Statement......................................17
*1. Introduction
   This document describes a mechanism to allow senders of an Internet
   mail message to convey the message's contextual information.  Taking
   account of this information, the receiving user agent (UA) can make
   decisions that improve message presentation for the user in the
   context the sender and receiver expects.
   In this document, the "message context" conveys information about the
   way the user expects to interact with the message.  For example, a
   message may be e-mail, voice mail, fax mail, etc.  A smart UA may
   have specialized behavior based on the context of the message.
   This document specifies a RFC 2822 header called "Message-Context".
   The mechanism is in some ways similar to the use of the Content-
   Disposition MIME entity described in [6].  Content-Disposition gives
   clues to the receiving User Agent (UA) for how to display a given
   body part.  Message-Context can give clues to the receiving UA for
   the presentation of the message.  This allows the receiving UA to
   present the message to the recipient, in a meaningful and helpful
   way.
   Typical uses for this mechanism include:
   o  Selecting a special viewer for a given message.
   o  Selecting an icon indicating the kind of message in a displayed
      list of messages.
   o  Arranging messages in an inbox display.
   o  Filtering messages the UA presents when the user has limited
      access.

2. Conventions used in this document この文書で使う記法

This document refers generically to the sender of a message in the masculine (he/him/his) and the recipient of the message in the feminine (she/her/hers). This convention is purely for convenience and makes no assumption about the gender of a message sender or recipient.

この文書では、messageの送信者を男性 (彼) とし、messageの受信者を女性 (彼女) として言及します。 この記法は単に便宜上のものであって、messageの送受信者の性別について何らの仮定をするものでもありません。

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 BCP 14, RFC 2119 [2]. JA:RFCKeywordsAre...> FORMATTING NOTE: Notes, such at this one, provide additional nonessential information that the reader may skip without missing anything essential. The primary purpose of these non-essential notes is to convey information about the rationale of this document, or to place this document in the proper historical or evolutionary context. Readers whose sole purpose is to construct a conformant implementation may skip such information. However, it may be of use to those who wish to understand why we made certain design choices.

整形について: このような注記は、非本質的な追加情報を提供するもので、 読者は本質的な事項を見落とすことなく読み飛ばすことが出来ます。 この非本質的な注記の主たる目的はこの文書の論理的根拠を伝えることやこの文書を適当な歴史的・進化上の位置に置くことです。 適合する実装を構築することだけが目的である読者はそのような情報を読み飛ばすことが出来ます。 しかし、どうしてこのような設計が選ばれたのかを理解したいと思う読者には役に立つことでしょう。

3. Motivation 動機

Multimedia messaging systems receive messages that a UA may present in variety of ways. For example, traditional e-mail uses simple text messages that the recipient displays and edits. One UA may automatically print Fax images. Another UA may play voice messages through a telephone handset. Likewise, a receiving desktop computer may process or present documents transferred over e-mail using a local application. Emerging and future developments may deliver other forms of information that have their own characteristics for user presentation, such as video messages and pager messages. multimediamessage systemは UA が種々の方法で表現し得るmessageを受信します。 例えば、伝統的なemailは、受信者が表示・編集する単純なtextmessageを使います。 ある UA は自動的にfax画像を印刷するかもしれません。 他の UA は電話受話器を通じてvoicemessageを再生するかもしれません。 同様に、受信したdesktop computeremailで転送された文書をlocal applicationを使って処理又は表現するかもしれません。 現在及び将来の開発者はvoicemessagepagermessageのように利用者への表現の性質を持った他の形式の情報を配送するかもしれません。

An often-requested characteristic for multimedia messaging systems is to collect received messages in a "universal inbox", and to offer them to the user as a combined list. multimediamessage systemでよく要求される性質は、受信messageを「universal inbox」に集めて、これを利用者に複合listとして提供することです。

In the context of "unified messaging", different message contexts may have different implied semantics. For example, some users may perceive voicemail to have an implicit assumption of urgency. Thus they may wish to gather them together and process them before other messages. This results in the end-user receiving agent needing to be able to identify voicemail and distinguish it from other messages.

unified messaging」の文脈では、異なるmessage文脈が異なる暗の意味を持ち得ます。 例えば、ある利用者はvoicemailを暗に緊急性を持つものとして理解するかもしれません。 従ってそうした利用者はそれを集めて他のmessageより先に処理することを望むでしょう。 この結果end userの受信agentvoicemailを識別して他のmessageから区別することが出来る必要があります。

The uses of this kind of presentation characteristic for each message are multi-fold:

この種の各messageの表現性質の利用は複数組まれています。

   o  Display an indication to the user (e.g., by a suitably evocative
      icon along with other summary fields),
   o  Auto-forward a given message type into another messaging
      environment (e.g., a page to a mobile short message service),
   o  Prioritize and group messages in an inbox display list,
   o  Suggest appropriate default handling for presentation,
   o  Suggest appropriate default handling for reply, forward, etc.

A problem faced by multimedia messaging systems is that it is not always easy to decide the context of a received message. For example, consider the following scenarios. multimediamessage systemが直面している問題は、受信messageの文脈を決定するのが必ずしも容易ではないことです。 例えば、次の場面を考えてください。

   o  A message that contains audio and image data:  Is this a fax
      message that happens to have some voice commentary?  Is it a voice
      message that is accompanied by some supplementary diagrams?  Is it
      a fully multimedia message, in which all parts are expected to
      carry equal significance?
voice

と画像のdataを含んだmessage。 これはfax&&message&&__にvoiceでメモが付いたものでしょうか。 それともvoicemessageに補足の図を付けたものでしょうか。 あるいは完全にmultimediamessageで、全ての部分を同様の重要度で伝えることを意図したものでしょうか。

   o  A message containing text and audio data:  Is this e-mail with an
      MP3 music attachment?  Is it a voice message that happens to have
      been generated with an initial text header for the benefit of
      non-voice-enabled e-mail receivers?
text

audiodataを含んだmessage。 このemailは MP3 音楽を添付したものでしょうか。 それともvoicemessagevoiceが使えないemail受信者向けの初期textheaderつきで生成されたvoicemessageでしょうか。

The message context does relate to the message media content. However, it is not the same thing. As shown above, the media type used in a message is not sufficient to indicate the message context. One cannot determine a priori which media types to use in alternative (gateway) messages. Also, what if the user cares about distinguishing traditional e-mail text from SMS messages? They are both the same media type, text, but they have different user contexts. message文脈はmessagemedia文脈とは関係はします。 しかし、これらは同じことではありません。 前に示したように、messsageで使われるmedia typemessage文脈を示す上では重要ではありません。 どのmedia typeを代替 (gateway) messageに使うのかの優先度は決定できません。 また、利用者が伝統的なemailtextと SMS messageを区別した意図したらどうでしょう。 両者は共に同じmedia typetextですが、異なる利用者文脈を持っています。

4. Functional Requirements 機能的要件

The goals stated above lead to the following functional requirements.

以上で述べた目標から次の要件が導かれます。

For receivers:

受信者について:

   o  Identify a message as belonging to a message class.
   o  Incorrect or invalid message classification must not result in
      failure to transfer or inability to present a message.

For senders:

送信者について:

   o  Specify message classes by the originating user's choice of
      authoring tool or simple user interaction.

For both:

両者について:

   o  Specify a well-defined set of message classes to make
      interoperability between mail user agents (UAs) possible.
   o  Message classification information has to be interpretable in
      reasonable fashion by many different user agent systems.
   o  The mechanism should be extensible to allow for the introduction
      of new kinds of messages.
   NOTE: We specifically do not specify user agent behavior when the
   user agent forwards a message.  Clearly, the user agent, being
   message-context-aware, should provide a meaningful message-context.
   It is obvious what to do for the easy cases.  Messages that the user
   simply forwards will most likely keep the context unchanged.
   However, it is beyond the scope of this document to specify the user
   agent behavior for any other scenario.

注意: 私達は、user agentmessageを転送する時のuser agentの動作を具体的には規定しません。 明らかに、user agentmessage文脈を知っているものは、意味のあるmessage文脈を提供するべきです。 簡単な場合には何をするのかは自明です。 利用者が単に転送するmessageでは文脈は変更しないでおくのが最も適当でしょう。 しかし、他の場面でのuser agentの動作についてはこの文書の適用範囲外です。

5. Determining the Message Context message文脈の決定

One method of indicating the interpretation context of a message is to examine the media types in the message. However, this requires the UA to scan the entire message before it can make this determination. This approach is particularly burdensome for the multi-media mail situation, as voice and especially video mail objects are quite large.

解釈したmessageの文脈を示す一つの方法は、message中のmedia typeを検査することです。 しかし、このために UA は、この決定をする前にmessage全体を走査しなければなりません。 この方法は特にmultimediamailの場合には重荷となります。 voiceや特にvideomailobjectは非常に大きくなりますから。

We considered indicating the message context by registering a multipart/* MIME subtype (Content-Type). For example, the VPIM Work Group has registered multipart/voice-message to indicate that a message is primarily voice mail [7]. However, multipart/voice-message is identical in syntax to multipart/mixed. The only difference is that VPIM mail transfer agents and user agents recognize that they can perform special handling of the message based on it being a voice mail message. Moreover, Content-Type refers to a given MIME body part, not to the message as a whole.

multipart/* MIME subtype (Content-Type) を登録することでmessage文脈を示すことも考えました。例えば、 VPIM work groupはあるmessageが主としてvoicemailであることを示すために multipart/voice-message を登録しました。 しかし、 multipart/voice-messagemultipart/mixed の構文と同一です。唯一の違いは、 VPIM mail転送agent及びuser agentがそのmessagevoicemailmessageであることに基づいた特別なmessageの取扱いを行うことが出来ると認識することです。 更に、 Content-Type は当該 MIME body partにのみ言及するのであって、message全体に言及するのではありません。

訳注: 構文が同じというのは、そもそも RFC2046 がそう規定している (multipart/* 参照。) からであって当然のことです。 (スコア -1: 余計なもの)

We wish to avoid scanning the entire message. In addition, we wish to avoid having to create multiple aliases for multipart/mixed every time someone identifies a new primary content type. Multiple aliases for multipart/mixed are not desirable as they remove the possibility for specifying a message as multipart/alternate, multipart/parallel, or multipart/encrypted, for example. messageの全体を走査することは避けたいと願っています。 加えて、誰かが新しい主content typeを識別する旅に複数の multipart/mixed の別名を作成しなければならないのは避けたいと願っています。 複数の multipart/mixed の別名は、messagemultipart/alternate, multipart/parallel, multipart/encrypted などとして指定する時の可搬性を損ないますから望ましくありません。

Since the message context is an attribute of the entire message, it is logical to define a new top-level (RFC 2822 [3]) message attribute. To this end, this document introduces the message attribute "Message-Context". message contextmessage全体の属性ですから、 新しいtop-level (RFC 2822) message属性を定義するのは論理的です。 この結論から、この文書はmessage属性 Message-Context を導入します。

Message-Context only serves to identify the message context. It does not provide any indication of content that the UA must be capable of delivering. It does not imply any message disposition or delivery notification. There is a related effort to define Critical Content of Internet Mail [8] that one might use to perform these tasks. Message-Contextは、message contextの識別のみのために供給されます。 これは UA が配送の能力を持っていなければならない内容を指示するものではありません。 これはいかなるmessage dispositiondelivery notificationを課すものでもありません。 こうした作業を行うのに使えるものとしては、関連してInternet MailCritical Contentを定義する仕事があります。

Message-Context is only an indicator. We do not intend for it to convey information that is critical for presentation of the message. One can conceive of goofy situations, such as a message marked "voice-message" but without an audio body part. In this case, the fact that the contents of a message don't match its context does not mean the receiving system should generate an error report or fail to deliver or process the message. Message-Contextは単なる指示子です。 これをmessageの表現にriticalであることの情報を運ぶのは意図していません。 voiced-messagemarkされているのにaudiobody partがないようなおかしな状況もあるかもしれません。 この場合、messageの内容がそのcontextに一致しなかったという事実は、 受信したsystemerror reportを生成したりmessageを配送したり処理したりするのに失敗したりするshouldということは意味しません。

6. Message-Context Reference Field Message-Contextreferencefield

The Message-Context reference field is a top-level header inserted by the sending UA to indicate the context of the message.

Message-Context referencefieldは、 送信 UA によりmessagecontextを示すために挿入されるtop-levelheaderです。

A receiving user agent MUST NOT depend on the indicated message-context value in a way that prevents proper presentation of the message. If the value is incorrect or does not match the message content, the receiving user agent MUST still be capable of displaying the message content at least as meaningfully as it would if no Message-Context value were present.

受信user agentは、messageの適当なpresentationを妨げる形で示されたmessage-context値に依存してはMUST NOT。 値が間違っているかmessage内容と一致しない時でも、 受信したuser agentは依然message内容を、 少なくても Message-Context 値が指定されていなかった場合と同程度には有意に表示できる能力がなければMUST

One can envision situations where a well-formed message ends up not including a media type one would expect from the message-context. For example, consider a voice messaging system that records a voice message and also performs speech-to-text processing on the message. The message then passes through a content gateway, such as a firewall, that removes non-critical body parts over a certain length. The receiving user agent will receive a message in the voice-message context that has only a text part and no audio. Even though the message does not have audio, it is still in the voice message context.

   Said differently, the receiving UA can use the message-context to
   determine whether, when, and possibly where to display a message.
   However, the message-context should not affect the actual rendering
   or presentation.  For example, if the message is in the voice-message
   context, then don't try to send it to a fax terminal.  Conversely,
   consider the case of a message in the voice-message context that gets
   delivered to a multimedia voice terminal with a printer.  However,
   this message only has fax content.  In this situation, the "voice-
   message" context should not stop the terminal from properly rendering
   the message.

6.1. Message-Context Syntax

   The syntax of the Message-Context field, described using the ABNF [4]
   is as follows.  Note that the Message-Context header field name and
   message-context-class values are not case sensitive.
      "Message-Context" ":" message-context-class CRLF

6.2. message-context-class Syntax

   The message-context-class indicates the context of the message.  This
   is an IANA registered value.  Current values for message-context-
   class are as follows.

Burger, et al. Standards Track [Page 7]  RFC 3458 Message Context for Internet Mail January 2003

      message-context-class =  (   "voice-message"
                                 / "fax-message"
                                 / "pager-message"
                                 / "multimedia-message"
                                 / "text-message"
                                 / "none"
                                )
   Note: The values for Message-Context MUST be IANA registered values
   following the directions in the IANA Considerations section below.

6.2.1. voice-message

   The voice-message class states the message is a voice mail message.

6.2.2. fax-message

   The fax-message class states the message is a facsimile mail message.

6.2.3. pager-message

   The pager-message class states the message is a page, such as a text
   or numeric pager message or a traditional short text message service
   (SMS) message.

6.2.4. multimedia-message

   The multimedia-message class states the message is an aggregate
   multimedia message, such as a message specified by [9].  This helps
   identify a message in a multimedia context.  For example, a MIME
   multipart/related [10] data part and resource part looks the same as
   a multimedia MHTML multipart/related.  However, the semantics are
   quite different.

6.2.5. text-message

   The text-message class states the message is a traditional internet
   mail message.  Such a message consists of text, possibly richly
   formatted, with or without attachments.

6.2.6. none

   The none class states there is no context information for this
   message.
   If a message has no Message-Context reference field, a receiving user
   agent MUST treat it the same as it would if the message has a "none"
   value.

Burger, et al. Standards Track [Page 8]  RFC 3458 Message Context for Internet Mail January 2003

7. Security Considerations

   The intention for this header is to be an indicator of message
   context only.  One can imagine someone creating an "Application"
   Message-Context.  A poorly designed user agent could blindly execute
   a mailed program based on the Message-Context.  Don't do that!
   One can envision a denial of service attack by bombing a receiver
   with a message that has a Message-Context that doesn't fit the
   profile of the actual body parts.  This is why the receiver considers
   the Message-Context to be a hint only.

8. IANA Considerations

   Section 8.3 is a registration for a new top-level RFC 2822 [3]
   message header, "Message-Context".
   This document creates an extensible set of context types.  To promote
   interoperability and coherent interpretations of different types, a
   central repository has been established for well-known context types.
   The IANA has created a repository for context types called "Internet
   Message Context Types".  Following the policies outlined in [5], this
   repository is "Specification Required" by RFC.  Section 8.1 describes
   the initial values for this registry.
   To create a new message context type, you MUST publish an RFC to
   document the type.  In the RFC, include a copy of the registration
   template found in Section 8.2 of this document.  Put the template in
   your IANA Considerations section, filling-in the appropriate fields.
   You MUST describe any interoperability and security issues in your
   document.

8.1. Message Content Type Registrations

   Internet Message Content Types
   ==============================
   Value              Description                           Reference
   -----              -----------                           ---------
   voice-message      Indicates a message whose primary     This RFC
                      content is a voice mail message.  The
                      primary content is audio data.  The
                      context is usually a message recorded
                      from a voice telephone call.

Burger, et al. Standards Track [Page 9]  RFC 3458 Message Context for Internet Mail January 2003

   fax-message        Indicates a message whose primary     This RFC
                      content is a fax mail message.  The
                      primary content is image data.  The
                      context is usually a message recorded
                      from a facsimile telephone call.
   pager-message      Indicates a message whose primary     This RFC
                      content is a page.  The primary
                      content is text data.  The context is
                      an urgent message usually of a
                      limited length.
   multimedia-message Indicates a message whose primary     This RFC
                      content is a multimedia message.  The
                      primary content is multimedia, most
                      likely MHTML.  The context is often
                      spam or newsletters.
   text-message       Indicates a classic, text-based,      This RFC
                      Internet message.
   None               Indicates an unknown message context. This RFC

8.2. Registration Template

   In the following template, a pipe symbol, "|", precedes instructions
   or other helpful material.  Be sure to replace "<classname>" with the
   class name you are defining.
   Message-Context class name:
   <classname>
   Summary of the message class:
       | Include a short (no longer than 4 lines) description or summary
       | Examples:
       |   "Palmtop devices have a 320x160 pixel display, so we can..."
       |   "Color fax is so different than black & white that..."
   Person & email address to contact for further information:
       | Name & e-mail

Burger, et al. Standards Track [Page 10] &#12; RFC 3458 Message Context for Internet Mail January 2003

8.3. Message-Context Registration

   To: iana@iana.org
   Subject: Registration of New RFC 2822 Header
   RFC 2822 Header Name:
   Message-Context
   Allowable values for this parameter:
   Please create a new registry for Primary Context Class
   registrations.  See section 8.1 of this document for the initial
   va