RFC2159 日本語訳
2159 A MIME Body Part for FAX. H. Alvestrand. January 1998. (Format: TXT=11471 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Alvestrand Request for Comments: 2159 UNINETT Category: Standards Track January 1998
Alvestrandがコメントのために要求するワーキンググループH.をネットワークでつないでください: 2159年のUNINETTカテゴリ: 標準化過程1998年1月
A MIME Body Part for FAX
ファックスのためのMIME身体の部分
Status of this Memo
この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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
1. Introduction
1. 序論
This document contains the definitions, originally contained in RFC 1494, on how to carry CCITT G3Fax in MIME, and how to translate it to its X.400 representation.
このドキュメントは元々RFC1494に含まれた定義を含んでいます、MIMEでどのようにCCITT G3Faxを運ぶか、そして、どのようにX.400表現にそれを翻訳するかに関して。
NOTE: At the moment, this format does not seem appropriate for a "general purpose image format for the Internet", if such a beast can exist. It exists only to carry information that is already in G3 Fax format, and may be usefully converted to other formats when used in specific contexts.
以下に注意してください。 現在、この形式は「インターネットへの汎用の画像形式」に適切に見えません、そのような野獣が存在できるなら。 それは存在していますが、G3ファックス形式には既にあって、特定の文脈で使用されると有効に他の形式に変換されるかもしれない情報を運びます。
2. The image/g3fax content-type
2. g3faxの満足しているイメージ/タイプ
This content-type is defined to carry G3 Facsimile byte streams.
この満足しているタイプは、G3 Facsimileバイト・ストリームを運ぶために定義されます。
In general, a G3Fax image contains 3 pieces of information:
一般に、G3Faxイメージは3つの情報を含んでいます:
(1) A set of flags indicating the particular coding scheme.
CCITT Recommendation T.30 defines how the flags are
transmitted over telephones. In this medium, the flags are
carried as parameters in the MIME content-type header
field.
(1) 特定のコード構成を示す1セットの旗。 CCITT Recommendation T.30は旗がどう電話の上に送られるかを定義します。 この媒体では、旗はMIME満足しているタイプヘッダーフィールドにおけるパラメタとして運ばれます。
(2) A structure that divides the bits into pages. CCITT
recommendation T.4 describes a "return to command mode"
string; this is used here to indicate page breaks.
(2) ビットをページに分割する構造。 CCITT推薦T.4は「コマンドモードへのリターン」ストリングについて説明します。 これは、ページブレークを示すのにここで使用されます。
Alvestrand Standards Track [Page 1] RFC 2159 MIME Body Part for FAX January 1998
Alvestrand標準化過程[1ページ]RFC2159は1998年1月にファックスのために身体の部分をまねます。
(3) For each page, a sequence of bits that form the encoding of
the image. CCITT recommendation T.4 defines the bit image
format. This is used without change. The highest bit of
the first byte is the first bit of the T.4 bitstream.
各ページ、イメージのコード化を形成するビットの系列のための(3)。 CCITT推薦T.4は噛み付いている画像形式を定義します。 これは変化なしで使用されます。 最初のバイトの最も高いビットはT.4 bitstreamの最初のビットです。
2.1. G3Fax Parameters
2.1. G3Faxパラメタ
The following parameters are defined:
以下のパラメタは定義されます:
(1) page-length - possible values: A4, B4 and Unlimited
(1)ページ長--可能な値: B4の、そして、無制限なA4
(2) page-width - possible values: A3, A4, B4
(2)ページ幅--可能な値: A3、A4、B4
(3) encoding - possible values: 1-dimensional, 2-dimensional,
Uncompressed
(3)コード化--可能な値: 1次元で、2次元で、解凍されています。
(4) resolution - possible values: Fine, Coarse
(4) 解決--可能な値: すばらしくて、粗いです。
(5) DCS - a bit string, represented in Base64.
(5)DCS--Base64に表されて、少し結びます。
(6) pages - an integer, giving the number of pages in the
document
(6)ページ--ドキュメントのページ数を与える整数
If nothing is specified, the default parameter settings are:
何も指定されないなら、デフォルトパラメタ設定は以下の通りです。
page-length=A4
page-width=A4
encoding=1-dimensional
resolution=Coarse
A4ページページ長=幅は=1次元の解決=をコード化するA4と粗い状態で等しいです。
Alvestrand Standards Track [Page 2] RFC 2159 MIME Body Part for FAX January 1998
Alvestrand標準化過程[2ページ]RFC2159は1998年1月にファックスのために身体の部分をまねます。
It is possible (but misleading) to view the representation of these values as single-bit flags. They correspond to the following bits of the T.30 control string and X.400 G3FacsimileParameters:
これらの値の表現を単一のビット旗であるとみなすのは、可能、そして、(紛らわしい。)です。 彼らはT.30コントロールストリングとX.400 G3FacsimileParametersの以下のビットに対応します:
Parameter T.30 bit X.400 bit
パラメタT.30ビットX.400は噛み付きました。
page-length=A4 no bit set
page-length=B4 19 21
page-length=Unlimited 20 20
噛み付かれなかったページ長=A4は無制限なB4 19 21ページ長=ページ長=20 20を設定します。
page-width=A4 no bit set
page-width=A3 18 22
page-width=B4 17 23
噛み付かれなかったページ幅=A4はA3 18 22ページページ幅=幅=B4 17 23を設定します。
encoding=1-dimensional no bit set
encoding=2-dimensional 16 8
encoding=Uncompressed 26 30
=をコード化する=1次元のノー噛み付いているセットコード化=2次元の16 8をコード化すると、26 30は解凍しました。
resolution=Coarse no bit set
resolution=Fine 15 9
解決は粗いノー噛み付いているセット解決=罰金15 9と等しいです。
The reason for the different bit numbers is that X.400 counts bits in an octet from the MSB down to the LSB, while T.30 uses the opposite numbering scheme.
異なった噛み付いている数の理由はX.400が八重奏でビットをMSBからLSBまで数えるということです、T.30が反対のナンバリングスキームを使用しますが。
If any bit but these are set in the Device Control String, the DCS parameter should be supplied.
Device Control Stringにこれらだけをどんなビット設定するならも、DCSパラメタを提供するべきです。
2.2. Content Encoding
2.2. 満足しているコード化
X.400 defines the g3-facsimile data stream as a SEQUENCE of BIT STRINGs. Each BIT STRING is a page of facsimile image data, encoded as defined by Recommendation T.4. The following content encoding is reversible between MIME and X.400 and ensures that page breaks are honored in the MIME representation.
X.400はg3-ファクシミリデータ・ストリームをBIT STRINGsのSEQUENCEと定義します。 各BIT STRINGはRecommendation T.4によって定義されるようにコード化された1ページのファクシミリイメージデータです。 以下の満足しているコード化は、MIMEとX.400の間でリバーシブルであり、ページブレークがMIME表現を光栄に思っているのを確実にします。
An EOL is defined as a bit sequence of
EOLはしばらく系列と定義されます。
000000000001 (eleven zeroes and a one).
000000000001 (11のゼロと1つ。)
Each page of the message is delimited by a sequence of six (6) EOLs that MUST start on a byte boundary. The image bit stream is padded with zeroes as needed to achieve this alignment.
メッセージの各ページはバイト境界を始めなければならない6(6)EOLsの系列によって区切られます。 イメージビットストリームは必要に応じてゼロで水増しされて、この整列を達成します。
Searching for the boundary is a matter of searching for the byte sequence (HEX) 00 10 01 00 10 01 00 10 01, which cannot occur inside the image.
境界を捜し求めるのは、バイト列(HEX)00 10 01 00 10 01 00 10 01を捜し求める問題です。(00 10 01 00 10 01 00 10 01はイメージで起こることができません)。
Alvestrand Standards Track [Page 3] RFC 2159 MIME Body Part for FAX January 1998
Alvestrand標準化過程[3ページ]RFC2159は1998年1月にファックスのために身体の部分をまねます。
See Section 7.5 for the algorithm on conversion between this encoding and the X.400 encoding.
アルゴリズムに関してこのコード化とX.400コード化の間の変換にセクション7.5を見てください。
The Base64 content-transfer-encoding is appropriate for carrying this content-type.
この満足しているタイプを運ぶのに、Base64の満足している転送コード化は適切です。
3. g3-facsimile - image/g3fax
3. g3-ファクシミリ--イメージ/g3fax
X.400 Body part: g3-facsimile MIME Content-Type: image/g3fax Conversion Type: nearly Byte copy Comments:
X.400身体の部分: g3-ファクシミリMIMEコンテントタイプ: イメージ/g3fax Conversion Type: ほとんどByteはCommentsをコピーします:
The Parameters of the X.400 G3Fax body part are mapped to the corresponding Parameters on the MIME Image/G3Fax body part and vice versa. Note that:
X.400 G3Fax身体の部分のParametersは逆もまた同様にMIME Image/G3Fax身体の部分の上の対応するParametersに写像されます。 以下のことに注意してください。
(1) If fineResolution is not specified, pixels will be twice as
tall as they are wide
(1) fineResolutionが指定されないと、画素はそれらが広いというよりも2倍高くなるでしょう。
(2) If any bit not corresponding to a specially named option is
set in the G3Fax NonBasicParameters, the "DCS" parameter
must be used.
(2) 何か特に、命名されたオプションと食い違っているビットがG3Fax NonBasicParametersに設定されるなら、「DCS」パラメタを使用しなければなりません。
(3) Interworking is not guaranteed if any bit apart from those
specially named are used in the NonBasicParameters
(3) 何か特に、指定されたものは別としてビットがNonBasicParametersで使用されるなら、織り込むことは保証されません。
From X.400 to G3Fax, the body is created in the following way:
X.400からG3Faxまで、ボディーは以下の方法で作成されます:
(1) Any trailing EOL markers on each bitstring is removed. The
bit order is changed to conform to the most common Internet
encoding (highest bit of first byte = first bit of the
G3Fax). The bitstring is padded to a byte boundary.
(1) いくらか、各bitstringのときにEOLマーカーを引きずるのを取り除きます。 (最初に、G3Faxの最初のビットのバイト=の最も高いビット)をコード化する最も一般的なインターネットに従うために噛み付いているオーダーを変えます。 bitstringはバイト境界に水増しされます。
(2) 6 consecutive EOL markers are appended to each bitstring.
(2) 6人の連続したEOLマーカーを各bitstringに追加します。
(3) The padded bitstrings are concatenated together
(3) そっと歩いているbitstringsは一緒に連結されます。
An EOL marker is the bit sequence 000000000001 (11 zeroes and a one).
EOLマーカーは噛み付いている系列000000000001です(11のゼロと1つ)。
From G3Fax to X.400, the body is created in the following way:
G3FaxからX.400まで、ボディーは以下の方法で作成されます:
(1) The body is split into bitstrings at each occurrence of 6
consecutive EOL markers. Trailing EOLs must NOT be removed,
since the X.400 Implementor Guide recommends that each page
should end with 6 consecutive EOLs. (This is a change from
RFC 1494).
(1) ボディーは6人の連続したEOLマーカーの各発生のときにbitstringsに分けられます。 引きずっているEOLsを取り外してはいけません、X.400 Implementorガイドが、各ページが6連続したEOLsと共に終わるはずであるのを推薦するので。 (これはRFC1494からの変化です。)
Alvestrand Standards Track [Page 4] RFC 2159 MIME Body Part for FAX January 1998
Alvestrand標準化過程[4ページ]RFC2159は1998年1月にファックスのために身体の部分をまねます。
(2) Each bitstring is made into an ASN.1 BITSTRING, reversing
the order of bits within each byte to conforom to the X.400
Implementors Guide recommendation for bit order in the
G3Fax body part.
(2) 各bitstringをASN.1BITSTRINGにします、G3Fax身体の部分で各バイトの中でビットの注文を噛み付いているオーダーのためのX.400 Implementorsガイド推薦へのconforomに逆にして。
(3) The bitstrings are made into an ASN.1 SEQUENCE, which forms
the body of the G3Fax body part.
(3) bitstringsをASN.1SEQUENCEにします。(SEQUENCEはG3Fax身体の部分のボディーを形成します)。
4. Usability of G3Fax body parts
4. G3Fax身体の部分のユーザビリティ
This section is not part of the proposed standard, but is intended as guidance for people implementing G3Fax handling, so that they know a little about what to expect.
このセクションは、提案された標準の一部ではありませんが、G3Fax取り扱いを実行する人々のための指導として意図します、彼らが予想するべきことに関して少し知るように。
The DCS bitstring is a LONG thing; the T.30 Recommendation (1993) gives 67 bits with specific functions, SG8 Report R33 extends this to 75 bits, and Report R41 (approved in 1995) extends it to 79 bits. (For curiosity - bit 68 says that the coding is JPEG; bit 27 is "error correcting mode). No sane implementor will send such things without being able to negotiate them down if the recipient doesn't support it, but there is no guarantee that messages with such bits set in the DCS won't arrive through X.400.
DCS bitstringはLONGものです。 T.30 Recommendation(1993)は具体的な機能がある67ビットを与えます、そして、SG8 Report R33はこれを75ビットまで広げています、そして、Report R41(1995年に承認される)はそれを79ビットまで広げています。 (ビット27がビット68が、コード化がJPEGであると言うという好奇心のための、そうである、「エラー修正モード)」 受取人がそれを支持しませんが、DCSに設定されたそのようなビットがあるメッセージがX.400を通して到着しないという保証が全くないと、どんな気が確かな作成者もそれらを交渉できる存在のないものが倒すそのようなものを送らないでしょう。
The ISO P2 profile from 1995 [PROFILE] says that the profile makes support for reception of two-dimensional and fine-resolution mandatory if g3-facsimile is supported at all. Research by Andrew Gordon of Net-Tel indicates that it is easy for an access unit to support fine resolution, unlimited length and B4 length, while support for B4 width is nearly impossible, and A3 width is hard.
1995年[PROFILE]からのISO P2プロフィールには、g3-ファクシミリが少しでも支持されるならプロフィールで二次元のレセプションのサポートと緻密な解像力が義務的になると書かれています。 ネット-Telのアンドリュー・ゴードンによる研究は、アクセスユニットが緻密な解像力、無制限な長さ、およびB4の長さを支持するのが、簡単であることを示します、B4幅のサポートはほとんど不可能です、そして、A3幅は困難ですが。
Another interesting point is that some fax machines have trouble if the scan lines do not contain exactly the declared number of pixels on each scan line, so "omitting right-hand white space" is likely to give trouble.
おもしろいもう1ポイントがスキャン線がそれぞれのスキャン線の上にちょうど画素の宣言している数を保管していないならいくつかのファックス装置が苦労するということであるので、「右手の余白を省略します」は問題を与えそうです。
5. Security Considerations
5. セキュリティ問題
There are no known security issues specific to the FAX body part.
FAX身体の部分に特定の安全保障問題は知られていません。
Alvestrand Standards Track [Page 5] RFC 2159 MIME Body Part for FAX January 1998
Alvestrand標準化過程[5ページ]RFC2159は1998年1月にファックスのために身体の部分をまねます。
6. References
6. 参照
[MIME]
Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
解放された[MIME]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[GUIDE]
X.400 Implementor's Guide, version 8.
[ガイド]X.400 Implementorのガイド、バージョン8。
[PROFILE]
ISO/IEC ISP 12062-2: 1995:
[プロフィール]ISO/IEC ISP12062-2: 1995:
[T.30]
ITU-T Recommendation T.30 (1993): Procedures for document
facsimile transmission in the general switched telephone network.
[T.30]ITU-T推薦T.30(1993): 司令官におけるドキュメントファクシミリ伝送のための手順は電話網を切り換えました。
7. Author's Address
7. 作者のアドレス
Harald Tveit Alvestrand UNINETT P.O.box 6883 Elgeseter N-7002 Trondheim NORWAY
ハラルドTveit Alvestrand UNINETT P.O.box6883Elgeseter N-7002トロンヘイムノルウェー
EMail: Harald.T.Alvestrand@uninett.no
メール: Harald.T.Alvestrand@uninett.no
Alvestrand Standards Track [Page 6] RFC 2159 MIME Body Part for FAX January 1998
Alvestrand標準化過程[6ページ]RFC2159は1998年1月にファックスのために身体の部分をまねます。
8. Full Copyright Statement
8. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Alvestrand Standards Track [Page 7]
Alvestrand標準化過程[7ページ]
一覧
スポンサーリンク
