RFC1741 日本語訳

Network Working Group                                       P. Faltstrom
Request for Comments: 1741                 Royal Institute of Technology
Category: Informational                                       D. Crocker
                                                  Brandenburg Consulting
                                                                 E. Fair
                                                     Apple Computer Inc.
                                                           December 1994

Faltstromがコメントのために要求するワーキンググループP.をネットワークでつないでください: 1741年のロイヤル工科大学カテゴリ: 晴れているE.アップルコンピーター社1994年12月に相談する情報のD.Crockerブランデンブルク

               MIME Content Type for BinHex Encoded Files

ビンヘックスのためのMIME content typeはファイルをコード化しました。

Status of this Memo

このMemoの状態

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

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

Abstract

要約

   This memo describes the format to use when sending BinHex4.0 files
   via MIME [BORE93].  The format is compatible with existing mechanisms
   for distributing Macintosh files.  Only when available software
   and/or user practice dictates, should this method be employed.  It is
   recommended to use application/applefile [FALT94] for maximum
   interoperability.

このメモはMIME[BORE93]でファイルをBinHex4.0に送るとき使用する形式について説明します。 マッキントッシュファイルを分配するのにおいて、形式は既存のメカニズムと互換性があります。 利用可能なソフトウェア、そして/または、ユーザ習慣が命令するときだけ、このメソッドは使われるべきですか? 最大限のインターオペラビリティに、アプリケーション/applefile[FALT94]を使用するのはお勧めです。

1.  Introduction

1. 序論

   Files on the Macintosh consists of two parts, called forks:

マッキントッシュのファイルはフォークと呼ばれる2つの部品から成ります:

   DATA FORK:       The actual data included in the file.  The Data
                    fork is typically the only meaningful part of a
                    Macintosh file on a non-Macintosh computer system.
                    For example, if a Macintosh user wants to send a
                    file of data to a user on an IBM-PC, she would only
                    send the Data fork.

データは分岐します: ファイルに実際のデータを含んでいます。 通常、Dataフォークは非マッキントッシュのコンピュータシステムのマッキントッシュファイルの唯一の重要な部分です。 例えば、マッキントッシュユーザがIBM-PCでデータのファイルをユーザに送りたい場合にだけ、彼女はDataフォークを送るでしょう。

   RESOURCE FORK:   Contains a collection of arbitrary attribute/value
                    pairs, including program segments, icon bitmaps,
                    and parametric values.

リソースフォーク: プログラム・セグメント、アイコンビットマップ、およびパラメトリック値を含む任意の属性/値の組の収集を含んでいます。

   Additional information regarding Macintosh files is stored by the
   Finder has in a hidden file, called the "Desktop Database".

マッキントッシュファイルを見なすのがFinderによって保存されるという追加情報は「デスクトップデータベース」と呼ばれる隠しファイルでそうしました。

   Because of the complications in storing different parts of a
   Macintosh file in a non-Macintosh filesystem that only handles
   consecutive data in one part, it is common to convert the Macintosh
   file into some other format before transferring it over the network.

一部で連続したデータを扱うだけである非マッキントッシュファイルシステムでマッキントッシュファイルの異なった部分を保存することにおける複雑さのために、ネットワークの上にそれを移す前にマッキントッシュファイルをある他の形式に変換するのは一般的です。

Faltstrom, Crocker & Fair                                       [Page 1]

RFC 1741             Content Type for BinHex Files         December 1994

ビンヘックスファイル1994年12月のためのFaltstrom、医者、および公正な[1ページ]RFC1741content type

   AppleDouble file format [APPL90], encoded in MIME as
   multipart/appledouble [FALT94] and application/applefile [FALT94] is
   the preferred format for a Macintosh file that is to be included in
   an Internet mail message, because it provides recipients with
   Macintosh computers the entire document, including Icons and other
   Macintosh specific information, while other users easily can extract
   the Data fork (the actual data).

複合/appledouble[FALT94]とアプリケーション/applefile[FALT94]としてMIMEでコード化されているのは、インターネットメール・メッセージに含まれることになっているマッキントッシュファイルのための都合のよい形式です、全体のドキュメントをマッキントッシュのコンピュータをもっている受取人に提供するので、Iconsと他のマッキントッシュ特殊情報を含んでいて、AppleDoubleファイル形式[APPL90]、他のユーザは容易に、Dataフォーク(実際のデータ)を抽出できますが。

   However, this specification provides for use of the currently popular
   BinHex4.0 encoding schemes, as a convinience to the installed base of
   users.

しかしながら、この仕様は体系をコード化する現在ポピュラーなBinHex4.0の使用に備えます、ユーザのインストールされたベースへのconvinienceとして。

2.  MIME format for BinHex4.0

2. BinHex4.0のためのMIME形式

   MIME-base Apple information is specified by:

MIMEベースアップル情報は以下によって指定されます。

   MIME type-name:            APPLICATION
   MIME subtype name:         MAC-BINHEX40
   Required parameters:       none
   Optional parameters:       NAME, which must be a "value" as
                              defined in RFC-1521 [BORE93].
   Encoding considerations:   none
   Security considerations:   See separate section in the document
   Published specification:   Appendix A
   Rationale:                 Permits MIME-based transmission of data
                              with Apple Macintosh file system specific
                              information using a currently popular,
                              though platform specific, format.

MIMEの種類名: APPLICATION MIME「副-タイプ」名: Mac-BINHEX40 Requiredパラメタ: なにも、Optionalパラメタ: NAME。(そのNAMEはRFC-1521[BORE93]で定義されるように「値」であるに違いありません)。 問題をコード化します: なにも、Security問題: ドキュメントPublished仕様で別々のセクションを見てください: 付録A原理: アップルのマッキントッシュファイルシステム特殊情報使用によるデータのMIMEベースの伝達に現在、ポピュラーで、もっとも、プラットホーム特有の形式を可能にします。

   2a.  Detail specific to MIME-based usage

2a。 MIMEベースの用法に特定の詳細

      Macintosh documents do not always need to be sent in a special
      format.  Those documents with well-known MIME types and non-
      existent or trivial resource forks can be sent as regular MIME
      body parts, without use of AppleSingle, AppleDouble or BinHex4.0.

マッキントッシュドキュメントは、いつも特別な形式で送られる必要があるというわけではありません。 通常のMIME身体の部分としてよく知られるMIMEの種類と非目下の、または、些細なリソースフォークがあるそれらのドキュメントを送ることができます、AppleSingle、AppleDoubleまたはBinHex4.0の使用なしで。

      Documents which lack a data fork must be sent as AppleSingle
      according to RFC 1740 [FALT94].

RFC1740[FALT94]に応じて、AppleSingleとしてデータフォークを欠いているドキュメントを送らなければなりません。

      Unless there are strong reasons not to, all other documents should
      be sent as AppleDouble according to RFC 1740 [FALT94].  This
      includes documents with non-trivial resource forks, and documents
      without corresponding well-known MIME types.

強い理由がない、RFC1740[FALT94]に応じて、AppleDoubleとして他のすべてのドキュメントを送るべきです。 これは重要なリソースフォークがあるドキュメント、および対応するよく知られるMIMEの種類のないドキュメントを含んでいます。

      It may be valuable in some cases to allow the user to choose one
      format over another, either because he disagrees with the
      implementor's definition of "trivial" resource forks, or for
      reasons of his own.

いくつかの場合、ユーザが別のものの上で1つの形式を選ぶのを許容するのは貴重であるかもしれません、彼が作成者の「些細な」リソースフォークの定義、または彼自身の理由で意見を異にするので。

Faltstrom, Crocker & Fair                                       [Page 2]

RFC 1741             Content Type for BinHex Files         December 1994

ビンヘックスファイル1994年12月のためのFaltstrom、医者、および公正な[2ページ]RFC1741content type

      Only when available software and/or user practice dictates, should
      BinHex 4.0 be employed.

利用可能なソフトウェア、そして/または、ユーザ習慣が命令するときだけ、ビンヘックス4.0は使われるべきですか?

3.  BinHex

3. ビンヘックス

   BinHex 4.0 is a propular means of encoding Macintosh files for
   archiving on non-Macintosh file systems and for transmission via
   Internet mail.  (See Appendix A for a brief description of the BinHex
   4.0 format.)

ビンヘックス4.0はインターネット・メールで非マッキントッシュファイルの上にシステムを格納して、トランスミッションのためのマッキントッシュファイルをコード化するpropular手段です。 (ビンヘックス4.0形式の簡単な説明に関してAppendix Aを見てください。)

   The content-type application/mac-binhex40 indicates that the body of
   the mail is a BinHex4.0 file.  Even though the BinHex encoding
   consists of characters which are not the same as those used in Base64
   (those regarded as safe according to RFC-1521 [BORE93]) a
   transportation encoding should not be done.

content typeアプリケーション/mac-binhex40は、メールのボディーがBinHex4.0ファイルであることを示します。 ものがBase64(RFC-1521[BORE93]によると、同じくらい安全な状態で見なされたもの)で輸送を使用したので、ビンヘックスコード化は同じでないキャラクタから成りますが、コード化するべきでないこと。

   Even though a BinHex file includes the original Macintosh filename,
   it is recommended that a name parameter be included on the Content-
   Type header to give the recipient a hint as to what file is attached.
   The value of the name parameter must be a "value" as defined by RFC-
   1521 [BORE93].  Note that this restricts the value to seven-bit US-
   ASCII characters.

ビンヘックスファイルはオリジナルのマッキントッシュファイル名を含んでいますが、名前パラメタがどんなファイルが添付しているかに関してヒントを受取人に与えるためにContentタイプヘッダーの上に含まれているのは、お勧めです。 RFC1521[BORE93]によって定義されるようにパラメタという名前の値は「値」でなければなりません。 これが値を7ビットの米国のASCII文字に制限することに注意してください。

   3a.  BinHex example

3a。 ビンヘックスの例

        Content-Type: application/mac-binhex40; name="car.hqx"

コンテントタイプ: アプリケーション/mac-binhex40。 名前="car.hqx"

            [The BinHex4.0 file goes here]

[BinHex4.0ファイルはここに動いています]

4.  References

4. 参照

   APPL90   AppleSingle/AppleDouble Formats for Foreign Files
            Developer's Note, Apple Computer, Inc., 1990.

APPL90 AppleSingle/AppleDoubleは外部ファイルのために開発者の注意、アップル・コンピューターInc.、1990をフォーマットします。

   FALT94   Faltstrom P., Crocker, D., and E. Fair, "MIME
            Encapsulation of Macintosh Files - MacMIME", RFC 1740,
            KTH, Brandenburg Consulting, Apple Computer Inc.,
            December 1994.

そして、FALT94 Faltstrom P.、クロッカー、D.、E. 公正に、「マッキントッシュファイルのカプセル化をまねてください--MacMIME」、RFC1740、KTH、ブランデンブルクのコンサルティング、アップルコンピーター社、1994年12月。

   BORE93   Borenstein N., and N. Freed, "MIME (Multipurpose Internet
            Mail Extensions): Mechanisms for Specifying and Describing
            the Format of Internet Message Bodies", RFC 1521, Bellcore,
            Innosoft, September 1993.

BORE93 Borenstein N.、および解放されたN.は「以下をまね(マルチパーパスインターネットメールエクステンション)」。 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、Bellcore、Innosoft、1993年9月。

Faltstrom, Crocker & Fair                                       [Page 3]

RFC 1741             Content Type for BinHex Files         December 1994

ビンヘックスファイル1994年12月のためのFaltstrom、医者、および公正な[3ページ]RFC1741content type

5.  Security Considerations

5. セキュリティ問題

   To the extent that application/mac-binhex40 facilitates the
   transmission of operating-system sensitive data, it may open a door
   for easier relaxation of security rules than is intended either by
   the sender of the administrator of the sender's system.

アプリケーション/mac-binhex40がオペレーティングシステム極秘データの伝達を容易にするという範囲まで、それはセキュリティ規則の送付者のシステムの管理者の送付者によって意図されるより簡単な緩和のために戸を開けるかもしれません。

6.  Acknowledgements

6. 承認

   Thanks to all of the people on the ietf-822 list who have provided
   much meaningful input for this document.  Some of them must though be
   remembered by name, because they have almost crushed my mailbox the
   last weeks with a very nice and interesting debate:

ietf-822リストの上のこのドキュメントのための多くの重要な入力を提供した人々のすべてをありがとうございます。 名前によって覚えていられますが、それらのいくつかがそうしなければなりません、彼らが最後の数週間非常に良くておもしろい討論で私のメールボックスをほとんどつぶしているので:

      Johan Berglund, Steve Dorner, David Gelhar, David Herron, Raymond
      Lau, Jamey Maze, John B. Melby, Jan Michael Rynning, Rens Troost,
      and Peter Svanberg.

ジョハンBerglund、スティーブ・デルナー、デヴィッドGelhar、デヴィッド・ハーロン、レイモンド・ラウ、Jamey馬瀬、ジョンB.Melby、ジャン・マイケルRynning、Rens Troost、およびピーター・スバンベルク。

7.  Authors' Addresses

7. 作者のアドレス

      Patrik Faltstrom
      Department of Numerical Analysis and Computing Science
      Royal Institute of Technology
      S-100 44 Stockholm
      Sweden

数値解析と電子計算学のロイヤル工科大学S-100 44ストックホルムスウェーデンのパトリクFaltstrom部

      EMail: paf@nada.kth.se

メール: paf@nada.kth.se

      Dave Crocker
      Brandenburg Consulting
      675 Spruce Dr.
      Sunnyvale, CA  94086

デーヴの医者ブランデンブルクのコンサルティング675はサニーベル博士、カリフォルニア 94086を小綺麗にします。

      EMail: dcrocker@mordor.stanford.edu

メール: dcrocker@mordor.stanford.edu

      Erik E. Fair
      Engineering Computer Operations
      Apple Computer Inc.

エリックE.の公正な工学コンピュータ操作アップルコンピーター社

      EMail: fair@apple.com

メール: fair@apple.com

Faltstrom, Crocker & Fair                                       [Page 4]

RFC 1741             Content Type for BinHex Files         December 1994

ビンヘックスファイル1994年12月のためのFaltstrom、医者、および公正な[4ページ]RFC1741content type

Appendix A.  The BinHex format

ビンヘックスがフォーマットする付録A.

   Here is a description of the Hqx7 (7 bit format as implemented in
   BinHex 4.0) formats for Macintosh Application and File transfers.

ここに、マッキントッシュApplicationのためのHqx7(ビンヘックス4.0で実装される7ビットの形式)形式とFile転送の記述があります。

   The main features of the format are:

形式に関する主な出し物は以下の通りです。

   1) Error checking even using ASCII download
   2) Compression of repetitive characters
   3) 7 bit encoding for ASCII download

1) ASCIIダウンロード2)を使用さえすることでチェックする誤り 反復性のキャラクタ3)の圧縮 ASCIIのためにダウンロードをコード化する7ビット

   The format is processed at three different levels:

形式は3つの異なったレベルで処理されます:

      1) 8 bit encoding of the file:

1) 8はファイルのコード化に噛み付きました:

   Byte:    Length of FileName (1->63)
   Bytes:   FileName ("Length" bytes)
   Byte:    Version
   Long:    Type
   Long:    Creator
   Word:    Flags (And $F800)
   Long:    Length of Data Fork
   Long:    Length of Resource Fork
   Word:    CRC
   Bytes:   Data Fork ("Data Length" bytes)
   Word:    CRC
   Bytes:   Resource Fork ("Rsrc Length" bytes)
   Word:    CRC

バイト: ファイル名(1>63)バイトの長さ: FileName(「長さ」バイト)バイト: バージョン長さ: 長い間、タイプしてください: 創造者Word: 旗(そして、$F800)は切望されます: 長さに関するデータは長い間、分岐します: リソースフォークWordの長さ: CRCバイト: データFork(「データの長さ」バイト)Word: CRCバイト: リソースFork(「Rsrcの長さ」バイト)Word: CRC

      2) Compression of repetitive characters.

2) 反復性のキャラクタの圧縮。

   ($90 is the marker, encoding is made for 3->255 characters)

(90ドルがマーカーである、コード化は3>の255のキャラクタのために作られています)

   00 11 22 33 44 55 66 77   -> 00 11 22 33 44 55 66 77
   11 22 22 22 22 22 22 33   -> 11 22 90 06 33
   11 22 90 33 44            -> 11 22 90 00 33 44

00 11 22 33 44 55 66 77->00 11 22 33 44 55 66 77 11 22 22 22 22 22 22 33->11 22 90 06 33 11 22 90 33 44->11 22 90 00 33 44

   The whole file is considered as a stream of bits.  This stream will
   be divided in blocks of 6 bits and then converted to one of 64
   characters contained in a table.  The characters in this table have
   been chosen for maximum noise protection.  The format will start
   with a ":" (first character on a line) and end with a ":".
   There will be a maximum of 64 characters on a line.  It must be
   preceded, by this comment, starting in column 1 (it does not start
   in column 1 in this document):

全体のファイルはビットの流れであるとみなされます。 このストリームは、6ビットのブロックで分割されて、次に、テーブルに含まれた64文字の1つに変換されるでしょう。 このテーブルのキャラクタは最大の雑音保護に選ばれました。 「形式はa」から始まるでしょう」 (最初に、系列のキャラクタ) 「そして、a」で以下を終わらせてください。」 最大64のキャラクタが系列にあるでしょう。 それに先行しなければなりません、このコメントで、コラム1で始まって(それはコラム1で本書では始まりません):

Faltstrom, Crocker & Fair                                       [Page 5]

RFC 1741             Content Type for BinHex Files         December 1994

ビンヘックスファイル1994年12月のためのFaltstrom、医者、および公正な[5ページ]RFC1741content type

    (This file must be converted with BinHex 4.0)

(ビンヘックス4.0でこのファイルを変換しなければなりません)

   Any text before this comment is to be ignored.

このコメントの前のどんなテキストも無視されることです。

   The characters used is:

使用されるキャラクタは以下の通りです。

    !"#$%&'()*+,- 012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr

」 #$%と'()*+ 012345689@ABCDEFGHIJKLMNPQRSTUVXYZ 、['abcdefhijklmpqr'

Faltstrom, Crocker & Fair                                       [Page 6]

Faltstrom、クロッカー、およびフェア[6ページ]