RFC 2913

RFC 2913

MIME Content Types in Media Feature Expressions 媒体表現式中の MIME 内容型

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

In "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags.

『媒体特徴集合の記述の構文』では、単純な特徴札を使って媒体特徴能力を記述するための式書式が示されています。

This memo defines a media feature tag whose value is a Multipurpose Internet Mail Extensions (MIME) content type. This allows the construction of feature expressions that take account of the MIME content type of the corresponding data.

このメモは値が多目的インターネット・メイル拡張 (MIME) 内容型である媒体特徴札を定義します。 これは対応するデータの MIME 内容型を考慮に入れた特徴式の構築を可能にします。

Table of Contents

   1. Introduction .................................................. 2
      1.1 Terminology and document conventions ...................... 2
   2. Motivation and goals .......................................... 3
   3. MIME content type feature tag ................................. 3
   4. Examples ...................................................... 4
      4.1 Simple text ............................................... 4
      4.2 Fax image ................................................. 4
      4.3 Voice message ............................................. 4
      4.4 Web browser capabilities .................................. 5
   5. IANA Considerations ........................................... 5
   6. Security Considerations ....................................... 5
   7. Acknowledgements .............................................. 5
   8. References .................................................... 6
   9. Author's Address .............................................. 6
   Appendix A: 'Type' feature tag registration ...................... 7
   Full Copyright Statement ......................................... 9

1. Introduction

In "A Syntax for Describing Media Feature Sets" [1], an expression format is presented for describing media feature capabilities as a combination of simple media feature tags, registered according to "Media Feature Tag Registration Procedure" [2]. This provides a format for message handling agents to describe the media feature content of messages that they can handle.

『媒体特徴集合の記述の構文』では、媒体特徴能力を 『媒体特徴札登録手続き』に従って登録された単純な媒体特徴札の組合せで記述するための式書式を示しています。 これはメッセージ取扱いエージェントが自らの取扱うことのできるメッセージの媒体特徴内容を記述するための書式を提供します。

This memo defines a media feature tag whose value is a MIME content type. This allows the construction of feature expressions that take account of the MIME content type of the corresponding data.

このメモは値が MIME 内容型である媒体特徴札を定義します。 これは、対応するデータの MIME 内容型を考慮に入れた特徴式の構築を可能とします。

Note that a content type feature value may contain parameters, but this is discouraged. See section 3 and appendix A, "Summary of the

 media features indicated" for discussion of this point.

内容型特徴値は引数を含むかもしれませんが、これは非推奨であることに注意して下さい。 この点の議論は3章と附属書 A 『示される媒体特徴のまとめ』 をご覧ください。

1.1 Terminology and document conventions

This section defines a number of terms and other document conventions, which are used with specific meaning in this memo.

この節は、このメモで特定の意味で使用される数々の用語と他の表記法を定義します。

media feature
information that indicates facilities assumed to be available for the message content to be properly rendered or otherwise presented. Media features are not intended to include information that affects message transmission.
feature set
some set of media features described by a media feature assertion, as described in "A Syntax for Describing Media Feature Sets" [1]. (See that memo for a more formal definition of this term.)
feature set expression
a string that describes some feature set, formulated according to the rules in "A Syntax for Describing Media Feature Sets" [1] (and possibly extended by other specifications).
媒体特徴
適切にレンダリングされるか、その他の方法で提示されるメッセージ内容に利用可能と想定される能力を示す情報。媒体特徴はメッセージ転送に影響する情報を含むことは意図していない。
特徴集合
媒体特徴表明で記述される媒体特徴の何らかの集合で、 『媒体特徴集合の記述の構文』で説明されている。 (この用語のより正式な定義はこのメモを参照。)
特徴集合式
特徴式集合を記述する文字列で、 『媒体特徴集合の記述の構文』の規則 (他の仕様書により拡張されているかもしれない。) に従って公式化される。

This specification uses syntax notation and conventions described in RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" [3].

この仕様書は RFC 2234 『構文指定用増補 BNF: ABNF』 で記述されている構文記法・表記法を使用します。

NOTE: Comments like this provide additional nonessential information about the rationale behind this document. Such information is not needed for building a conformant implementation, but may help those who wish to understand the design in greater depth.

注意: このような注釈はこの文書の事情についての追加の本質的でない説明を提供します。 このような情報は適合実装の構築のためには必要ではありませんが、 設計をより深く理解したいと思う人の助けとなるやもしれません。

2. Motivation and goals

The media feature expression syntax [1] and feature tags [2] were designed with a view to providing content media information that augments basic MIME content type information. There are some situations where it is useful to be able include that content type information in a media feature expression:

媒体特徴式構文と特徴札は基本の MIME 内容型情報を補う内容媒体情報を提供することを目的として設計されました。 内容型情報を媒体特徴式に含めることができると便利な状況が幾つかあります。

  • o Media feature details may depend upon the content type being used. The media feature combining algebra and syntax [1] cannot apply to content type information unless it appears in the feature expression.
    • For example, in HTTP 1.1 [4] with Transparent Content Negotiation (TCN) [5] acceptable content types and other media features are indicated in different request headers, with no clear way to indicate that they may be acceptable only in certain combinations.
  • o It is sometimes useful for all media capability information to be included in a single expression. For example, DSN and MDN extensions [6] that allow a recipient to indicate media capabilities provide a single field for conveying this information.
  • o When media features are used to describe a message content, they may refer to inner parts of a MIME composite; e.g. the component parts of a 'multipart', files in a compressed archive, or encrypted message data.

3. MIME content type feature tag

   Feature tag name    Legal values
   ----------------    ------------
   type                <string>
                       containing a MIME content-type value.
特徴札名合法値
type<string> (MIME 内容型値を含んでいる)

Reference: this document, appendix A.

参照: この文書、附属書 A

The 'type' feature tag indicates a MIME media content type (i.e. that appears in a 'Content-type:' header of the corresponding MIME-formatted data). It must be a string of the form "type/subtype", where 'type' and 'subtype' are defined by the MIME specification [7]. Only lower-case letters should be used.

type 特徴札は MIME 媒体内容型 (すなわち、 対応する MIME 書式付けされたデータの Content-type: 頭に出現するもの) です。 これは type/subtype の形の文字列でなければなりません。 ここで typesubtype は MIME 仕様書で定義されています。 小文字だけを使用するべきです。

The content type must be given without any content-type parameter values.

内容型は一切の内容型引数値なしで与えなければなりません。

To include information in media feature expressions that is otherwise conveyed in a MIME content-type parameter, a separate media feature tag should be registered [2] and used in the media feature expression. This is illustrated by the use of 'charset' in the example at 4.1 below -- the 'charset' tag is defined by a separate registration [10].

本来 MIME 内容型引数で運搬される媒体特徴式中の情報を含めるためには、 別の媒体特徴札を登録して媒体特徴式で使用するべきです。 これは後の 4.1 の例の charset の使用で示しています。 charset 札は別の登録で定義されています。

NOTE: Allowing content-type parameters to be part of a type tag value was considered, but rejected because of concerns about canonicalization, ordering, case sensitivity, etc. Only exact, case-sensitive, character matching is defined for media feature expressions [1].

注意: 内容型引数を型札値の一部として認めることも検討しましたが、 正準化や順序付けや大文字・小文字の区別その他の心配があることから却下しました。 媒体特徴式には正確な大文字・小文字を区別する文字一致だけが定義されています。

4. Examples

4.1 Simple text

      (& (type="text/plain") (charset=US-ASCII)
         (color=binary) (paper-size=A4) )

4.2 Fax image

      (& (type="image/tiff")
         (color=binary)
         (image-file-structure=TIFF-S)
         (dpi=200)
         (dpi-xyratio=[200/100,200/200])
         (paper-size=A4)
         (image-coding=MH) (MRC-mode=0)
         (ua-media=stationery) )

4.3 Voice message

      (& (type="multipart/voice-message")
         (VPIM-version="3.0")
         (audio-codec=[G726-32,GSM-610])
         (audio-file-structure=[None,WAV])
         (ua-terminal=mobile-handset)
         (audio-channels=1) )

NOTE: in this case, some media features apply to MIME parts contained within the declared 'multipart/voice- message' content type. The goal here is not so much to mirror the MIME structure as to convey useful information about the (possible) message content.

注意: この場合、宣言された multipart/voice-message 内容型の中に含まれる MIME 部分に適用される媒体特徴もあります。 ここでの目標は MIME 構造の鏡像ではなく、 (可能な) メッセージ内容についての有用な情報を運搬することです。

4.4 Web browser capabilities

      (& (pix-x<=800) (pix-y<=600)
         (| (& (type="text/html") (charset=iso-8859-1)
               (color=limited) )
            (& (type="text/plain") (charset=US-ASCII) )
            (& (type="image/gif") (color=mapped))
            (& (type="image/jpeg") (color=full) ) ) )

This example describes an HTML viewer that can deal with a limited number of color text tags, a gif viewer that supports mapped color, and a jpeg viewer that supports color.

この例は限られた数の色文札を処理できる HTML 閲覧器と写像色に対応した gif 閲覧器と色に対応した jpeg 閲覧器を記述しています。

5. IANA Considerations

Appendix A of this document calls for registration of a feature tag in the "IETF tree", as defined in section 3.1.1 of "Media Feature Tag Registration Procedure" [2] (i.e. these feature tags are subject to the "IETF Consensus" policies described in RFC 2434 [9]).

この文書の附属書 A は『媒体特徴札登録手続き』の3.1.1節で定義されている 「IETF 木」への特徴札の登録を呼び出します (つまり、この特徴札は RFC 2434 で記述されている 「IETF 合意」方針の対象です)。

ASN.1 identifier 1.3.6.1.8.1.30 has been assigned by the IANA for this registered feature tag and has been placed in the body of the registration.

ASN.1 識別子 1.3.6.1.8.1.30IANA によりこの登録特徴札に割当てられ、登録の本体に置かれています。

6. Security Considerations

This memo is not believed to introduce any security considerations that are not already inherent in the use of media feature tags and expressions [1,2].

このメモはそもそもの媒体特徴札・式の使用によって既に存在しない安全上の問題を導入することはないと信じています。

7. Acknowledgements

This proposal draws from discussions in the IETF 'conneg' working group. The voice message example is based on some ideas by Glen Parsons.

この提案は IETF conneg 作業部会での議論から引出しました。 音声メッセージ例は Glen Parsons の考えに基づきました。

The author would like to thank the following people who offered comments that led to significant improvements: Ted Hardie, Larry Masinter, Paul Hoffman, Jacob Palme, Ned Freed.

著者は重大な改善につながるご意見をくださった次の方々に感謝します。 Ted Hardie, Larry Masinter, Paul Hoffman, Jacob Palme, Ned Freed

8. References

   [1]  Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
        2533, March 1999.
   [2]  Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
        Registration Procedure", RFC 2506, March 1999.
   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.
   [4]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
        Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
        2068, January 1997.
   [5]  Holtman, K. and A. Mutz, "Transparent Content Negotiation in
        HTTP", RFC 2295, March 1998.
   [6]  Wing, D., "Indicating Supported Media Features Using Extensions
        to DSN and MDN", RFC 2530, March 1999.
   [7]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, November 1996.
   [8]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Two: Media Types", RFC 2046, November
        1996.
   [9]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", RFC 2434, October 1998.
  [10]  Hoffman, P., "Registration of Charset and Languages Media
        Features Tags", Work in Progress.

9. Author's Address

   Graham Klyne
   Content Technologies Ltd.
   1220 Parkview,
   Arlington Business Park
   Theale
   Reading, RG7 4SA
   United Kingdom
   Phone: +44 118 930 1300
   Fax:   +44 118 930 1301
   EMail: GK@ACM.ORG

Appendix A: 'Type' feature tag registration

   -  Media Feature tag name(s):
         Type
   -  ASN.1 identifier associated with this feature tag:
         1.3.6.1.8.1.30
   -  Summary of the media features indicated:
         This feature tag indicates a MIME content type that a message
         agent is capable of handling, or that is contained within some
         message data.
         The content type consists of the MIME media type and subtype,
         presented using all lower case letters and with any whitespace
         characters removed.

この特徴札はメッセージ・エージェントが取扱うことのできる、または何らかのメッセージ・データに含まれている MIME 内容型を示します。

内容型は MIME 媒体型と亜型で構成し、すべて小文字を使って、空白文字は削除して示します。

   -  Values appropriate for use with this feature tag:
         String
   -  The feature tag is intended primarily for use in the following
      applications, protocols, services, or negotiation mechanisms:
         Any application that wishes to convey MIME content type
         information in a media feature expression.

MIME 内容型情報を媒体特徴式で運搬したいと思う任意の応用。

   -  Examples of typical use:
         (type="image/tiff")
         (& (type="text/plain") (charset=US-ASCII) )
   -  Related standards or documents:
         MIME, RFC 2045 [7]
         MIME, RFC 2046 [8]
         Registration of Charset and Languages Media Features Tags [10]
   -  Considerations particular to use in individual applications,
      protocols, services, or negotiation mechanisms:
         (N/A)
   -  Interoperability considerations:
         String feature matching is case sensitive, so consistent use of
         case for content type values and parameters is essential if
         content type value matching is to be achieved in a fashion
         consistent with MIME content type matching.
         Similarly, white space must be used consistently.
         This registration specifies a canonical form to be used for
         content type values (lower case letters and remove all
         whitespace).

文字列特徴一致は大文字・小文字を区別しますから、内容型値の一致が MIME 内容型一致と一貫した方法で達成されるのであれば内容型値と引数の大文字・小文字の一貫した使用が本質的です。

同様に、空白は一貫して使用してはなりません。

この登録は内容型値に使用する正準形 (小文字ですべての空白を削除) を規定します。

   -  Related feature tags:
         (N/A)
   -  Intended usage:
         Common
   -  Author/Change controller:
         IETF

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

メモ