[19] [[RFC 1505]] の規定する [DFN[[CODE(822)@en[Encoding:]] [[頭欄]]]]は、 [[メッセージ]]の[[本体]]の[[符号化]]方式を指定します。 [20] [[RFC 822]] [[メッセージ]]は[[頭部]]と[[本体]]で構成され、 両者は[[空行]]で分けられています。 [[RFC 1505]] は、このうちの[[本体]]の部分を更に構造化し、 1つ以上の[DFN[[RUBY[[[部分]]][ぶぶん]@en[part]]]] ([DFN[[RUBY[[[本体部分]]][ほんたいぶぶん]@en[body part]]]]) により構成されるとしています。 各[[部分]]の[[行数]]と書式 ([[符号化]]) は、 [CODE(822)@en[[[Encoding]]:]] [[頭欄]]で指定します。 更に、各[[部分]]の間には[[空行]]を挿入します。 [21] [[RFC 1505]] の提案する方式は、実際にはほとんど使われませんでした。 同様の機構である [[MIME]] がよく用いられています。 * 仕様書 [REFS[ - [27] [[RFC 1154]] ([[実験的]]) -- [29] [CITE@en[[[RFC 1154]] - Encoding header field for internet messages]], [TIME[2021-01-24T13:41:10.000Z]], [TIME[2021-03-13T07:51:24.521Z]] -- [30] [[RFC 1505]] により[[廃止]] - [36] [[RFC 1505]] ([[実験的]]) -- [37] [CITE@en[RFC 1505 - Encoding Header Field for Internet Messages]], [TIME[2021-02-01T01:04:32.000Z]], [TIME[2021-03-14T03:08:08.213Z]] - [38] [CITE[Mail Encoding Header Field Keywords]] ([TIME[2014-01-30 17:45:18 +09:00]] 版) ]REFS] ** RFC 1154 [FIG(quote)[ [31] >>29 '''Encoding Header Field for Internet Messages''' - Network Working Group - Request for Comments: 1154 - D. Robinson - R. Ullmann - Prime Computer, Inc. - April 1990 * 1. Status of the Memo > This RFC proposes an elective experimental Encoding header field to permit the mailing of multi-part, multi-structured messages. この [[RFC]] は多部分・多構造化[[メッセージ]]を[[メイル]]するための選択実験的な [CODE(822)[[[Encoding]]]] [[頭欄]]を提案します。 > The use of Encoding updates RFC 1049 (Content-Type), and is a suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement) [4,7,8]. [CODE(822)[[[Encoding]]]] の使用は [[RFC 1049]] ([CODE(822)[[[Content-Type]]]]) を更新すると共に、 [[RFC 1113]], [[RFC 1114]], [[RFC 1115]] (私匿性拡展) の更新を提案するものであります。 > Distribution of this memo is unlimited. このメモの配布は無制限とします。 * 2. Introduction > RFC 822 [2] defines an electronic mail message to consist of two parts, the message header and the message body, separated by an apparently blank line. [[RFC 822]] は[[電子メイル]]の[[メッセージ]]を空行で区切った[[メッセージ頭部]]と[[メッセージ本体]]の2つの部分で構成されるものとして定義しています。 > The Encoding header field permits the message body itself to be further broken up into parts, each part also separated from the next by an apparently blank line. [CODE(822)[[[Encoding]]]] 頭欄は[[メッセージ本体]]の部分を更に空行で区切った複数の部分に分けられるようにします。 > Thus, conceptually, a message has a header part, followed by one or more body parts, all separated by blank lines. 従って、[[メッセージ]]は概念的に空行で区切られる頭部分と 1つ以上の[[本体部分]]を持つこととなります。 > Each body part has an encoding type. The default (no Encoding field in the header) is a message body of one part of type "text". 各[[本体部分]]は符号化型を持ちます。 既定値 ([CODE(822)[[[Encoding]]]] 欄が頭にない場合) は [CODE(822)[[[text]]]] 型の部分が1つとなります。 * 3. The Encoding Field > The Encoding field consists of one or more subfields, separated by commas. Each subfield corresponds to a part of the message, in the order of that part's appearance. A subfield consists of a line count, a keyword defining the encoding, and optional information relevant only to the specific encoding. The line count is optional in the last subfield. [CODE(822)[[[Encoding]]]] 欄は[[読点]]で分離した1つ以上の部分欄から成ります。 各部分欄は[[メッセージ]]の各部分と出現順に対応します。 部分欄は行数、符号化を表す[[鍵語]]、省略可能な特定の符号化にだけ関係する情報で構成します。 行数は最後の部分欄では省略可能です。 ** 3.1. Format of the Encoding Field > The format of the Encoding field is: [CODE(822)[[[Encoding]]]] 欄の書式は次の通りです。 > [ [], ]* [] [] > where: ここで、 > [PRE[ := a decimal integer := a single alphanumeric token starting with an alpha := keyword-dependent options ]PRE] :[VAR[count]]:[[十進整数]] :[VAR[keyword]]:[[英字]]で始まる[[英数字]]の[[字句]]1つ :[VAR[options]]:[VAR[keyword]] に依存する選択肢 ** 3.2. > The line count is a decimal number specifying the number of text lines in the part. Parts are separated by a blank line, which is not included in the count of either the proceeding or following part. Because a count always begins with a digit and a keywords always begins with an letter, it is always possible to determine if the count is present. (The count is first because it is the only information of interest when skipping over the part.) 行数はその部分に含まれる文章の行の数を十進数で指定します。 部分と部分は空行で分離しますが、この空行は前後どちらの部分の行数にも含めません。 行数は常に数字で始まり、鍵語は常に英字で始まるので、 行数が指定されているかどうかを常に判定可能です。 (部分を1つ読み飛ばすために必要なのは行数だけですから、 行数を最初に置いています。) > The count is not required on the last or only part. 行数は最後の部分や部分が1つだけの時には必須ではありません。 ** 3.3. > The keyword defines the encoding type. The keyword is a common single word name for the encoding type. The keywords are not case-sensitive. 鍵語は符号化型を指定します。鍵語は符号化型を表す共通の 1語の名前です。鍵語は大文字・小文字を区別しません。 > The list of standard keywords is intended to be the same as the list used for the Content-Type: header described in [6]. This RFC proposes additions to the list. Implementations can then treat "Content-Type" as an alias of "Encoding", which will always have only one body part. 標準の鍵語は [[RFC 1049]] で説明されている [CODE(822)[[[Content-Type]]]] 頭で使うものと同じとすることを考えています。この [[RFC]] はそれへの追加の値も提案しています。実装は [CODE(822)[[[Content-Type]]]] を常に1つだけしか[[本体部分]]を持たない [CODE(822)[[[Encoding]]]] の別名として扱うことができます。 ** 3.4. > The optional information is used to specify additional keyword-specific information needed for interpreting the contents of the encoded part. It is any sequence of tokens not containing a comma. 省略可能な情報で、鍵語に依存して符号化部分の内容を解釈するのに必要な情報を指定するために使います。 [[読点]]を含まない任意の字句列です。 ** 3.5. Encoding Version Numbers > In general, version numbers for encodings, when not actually available within the contents of the encoded information, will be handled as options. 通常符号化の版番号は、 符号化された情報の内容に実際に利用できない時に選択肢として扱います。 ** 3.6. Comments > Comments enclosed in parentheses may, of course, be inserted anywhere in the Encoding field. Mail reading systems may pass the comments to their clients. Comments must not be used by mail reading systems for content interpretation; that is the function of options. 括弧で括られた[[注釈]]は当然 [CODE(822)[[[Encoding]]]] 欄内のどこにでも挿入できます。メイル読取りシステムは[[注釈]]を[[クライアント]]に渡しても構いません。 [[注釈]]をメイル読み取りシステムが内容の解釈のために使用してはなりません。 あくまでもおまけの機能です。 * 4. Encodings > This section describes some of the defined encodings used. この章では使用する符号化のいくつかを説明します。 > As with the other keyword-defined parts of the header format standard, extensions in the form of new keywords are expected and welcomed. Several basic principles should be followed in adding encodings: 頭の書式の規格の他の鍵語で定義する部分同様に新しい鍵語の拡張が予期・ 歓迎されます。符号化を追加するときは幾つかの基本的な原則に従うべきです。 > - The keyword should be the most common single word name for the encoding, including acronyms if appropriate. The intent is that different implementors will be likely to choose the same name for the same encoding. 鍵語は符号化の1単語の最も共通な名前を、適当なら略称を含めて使うべきです。 そうすれば異なる実装が同じ符号化に同じ名前を選ぶでしょう。 > - Keywords not be too general: "binary" would have been a bad choice for the "hex" encoding. 鍵語は一般的過ぎないように。 [CODE[binary]] を [Q[hex]] 符号化に使うのはよくないでしょう。 > - The encoding should be as free from unnecessary idiosyncracies as possible, except when conforming to an existing standard, in which case there is nothing that can be done. 符号化はできる限り特異的でないものとするべきです。 ただし既存の規格に適合する場合はどうしようもありません。 > - The encoding should, if possible, use only the 7 bit ASCII printing characters if it is a complete transformation of a source document (e.g., "hex" or "uuencode"). If it is essentially a text format, the full range may be used. If there is an external standard, the character set may already be defined. 符号化は原始文書の完全な変形なら可能な限り7ビット [[ASCII]] 印字[[文字]]だけを使うべきです (例えば [Q[[[hex]]]] や [Q[[[uuencode]]]])。 本質的に文章書式なら自由な範囲を使って構いません。 外部規格なら[[文字集合]]は既に定義されているかもしれません。 > Keywords beginning with "X-" are permanently reserved to implementation-specific use. No standard registered encoding keyword will ever begin with "X-". [CODE(822)[[[X-]]]] で始まる[[鍵語]]は実装規定の用法に恒久的に予約します。 標準登録符号化鍵語が [CODE(822)[[[X-]]]] から始まることはありません。 ** 4.1. Text > This indicates that the message is in no particular encoded format, but is to be presented to the user as is. これはメッセージが特定の符号化書式を使っておらず、 利用者にそのまま提示されることを示します。 > The full range of the ASCII character set is used. The message is expected to consist of lines of reasonable length (less than 1000 characters). [[ASCII]] [[文字集合]]の範囲を自由に使えます。メッセージは適度な長さ (1000文字未満) の行から成ることが期待されます。 > On some transport services, only the 7 bit subset of ASCII can be used. Where full 8 bit transparency is available, the text is assumed to be ISO 8859-1 [3] (ASCII-8). 転送サービスによっては [[ASCII]] の7ビットの[[部分集合]]だけ使えます。 完全に8ビット透過なところでは文章は [[ISO/IEC 8859]]‐1 ([[ASCII-8]]) と仮定します。 ** 4.2. Message > This encoding indicates that the body part is itself in the format of an Internet message, with its own header part and body part(s). A "message" body part's message header may be a full internet message header or it may consist only of an Encoding field. この符号化は本体部分自体が頭部分と本体部分(群)を持ったインターネット・メッセージの書式であることを示します。 [CODE(822)[[[message]]]] 本体部分のメッセージ頭部は完全なインターネット・メッセージ頭部でも構いませんし、 [CODE(822)[[[Encoding]]]] 欄だけであっても構いません。 > Using the message encoding on returned mail makes it practical for a mail reading system to implement a reliable resending function, if the mailer generates it when returning contents. It is also useful in a "copy append" MUA operation. 返却メイルにメッセージ符号化を使えば、 メイル読取りシステムが内容を返却するときにメイル器がこれを生成すれば確実に再送信する機能を実装できます。 [Q[複製して追記]]する [[MUA]] の操作でも便利です。 > Message encoding is also used when mapping to X.400 to handle recursively included X.400 P2 messages. メッセージ符号化は [[X.400]] への写像で [[X.400]] P2 [[メッセージ]]を再帰的に含むのを扱う時にも使えます。 ** 4.3. Hex > The encoding indicates that the body part contains binary data, encoded as 2 hexadecimal digits per byte, highest significant nibble first. この符号化は本体部分がバイナリ・データを 1バイト辺り十六進数字2桁 (最上位[[ニブル]]を最初に) で符号化して含むことを示します。 > Lines consist of an even number of hexadecimal digits. Blank lines are not permitted. The decode process must accept lines with between 2 and 1000 characters, inclusive. 十六進数字偶数個の行から成ります。空行は認められません。 符号化処理は文字数2文字以上1000文字以下 (両端を含みます。) の行を受付けなければなりません。 ** 4.4. EVFU > EVFU (Electronic Vertical Format Unit) specifies that each line begins with a one-character "channel selector". The original purpose was to select a channel on a paper tape loop controlling the printer. [PRE[ This encoding is sometimes called "FORTRAN" format. It is the default output format of FORTRAN programs on a number of computer systems. ]PRE] [PRE[ The legal characters are '0' to '9', '+', '-', and space. These correspond to the 12 rows (and absence of a punch) on a printer control tape (used when the control unit was electromechanical). ]PRE] [PRE[ The channels that have generally agreed definitions are: ]PRE] [PRE[ 1 advances to the first print line on the next page 0 skip a line, i.e., double-space + over-print the preceeding line - skip 2 lines, i.e., triple-space (space) print on the next line, single-space ]PRE] ** 4.5. EDI [PRE[ The EDI (Electronic Document Interchange) keyword indicates that the message or part is a business document, formatted according to ANSI X12 or related standards. ]PRE] [PRE[ The first word after the EDI keyword indicates the particular interchange standard. ]PRE] [PRE[ A message containing a note and 2 X12 purchase orders might have an encoding of: ]PRE] [PRE[ Encoding: 17 TEXT, 146 EDI X12, 69 EDI X12 ]PRE] ** 4.6. X.400 [PRE[ The Encoding header field provides a mechanism for mapping multi-part messages between CCITT X.400 [1] and RFC 822. ]PRE] [PRE[ The X.400 keyword specifies a section that is converted from an X.400 body part type not known to the gateway, or not corresponding to a useful internet encoding. ]PRE] [PRE[ If the message transits another gate, or if the receiving user has the appropriate software, it can be decoded and used. ]PRE] [PRE[ The X.400 keyword is followed by a second token indicating the method used. The simplest form is "X.400 HEX", with the complete X.409 encoding of the body part in hexadecimal. More compact is "X.400 3/4", using the 3-byte to 4-character encoding as specified in RFC 1113, section 4.3.2.4. ]PRE] ** 4.7. uuencode [PRE[ The uuencode keyword specifies a section consisting of the output of the uuencode program supplied as part of uucp. ]PRE] ** 4.8. encrypted [PRE[ The encrypted keyword indicates that the section is encrypted with the methods in RFC 1115 [8]. This replaces the possible use of RFC 934 [5] encapsulation. ]PRE] * References [PRE[ [1] International Telegraph and Telephone Consultative Committee, "Data Communication Networks: Message Handling Systems", In CCITT Recommendations X.400 to X.430, VIIIth Plenary Assembly, Malaga- Torremolinos, 1984, Fascicle VIII.7 ("Red Book"). ]PRE] [PRE[ [2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, University of Delaware, August 1982. ]PRE] [PRE[ [3] International Organization for Standardization, "Information processing - 8-bit single-byte coded graphic character sets - Part 1: Latin alphabet No. 1", ISO 8859-1, ISO, 1987. ]PRE] [PRE[ [4] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I -- Message Encipherment and Authentication Procedures", RFC 1113, IAB Privacy Task Force, August 1989. ]PRE] [PRE[ [5] Rose, M., and E. Stefferud, "Proposed Standard for Message Encapsulation", RFC 943, University of Delaware and NMA, January 1985. ]PRE] [PRE[ [6] Sirbu, M., "Content-type Header Field for Internet Messages", RFC 1049, CMU, March 1988. ]PRE] [PRE[ [7] Kent, S., and J. Linn, "Privacy Enhancement for Internet Electronic Mail: Part II -- Certificate-Based Key Management", RFC 1114, IAB Privacy Task Force, August 1989. ]PRE] [PRE[ [8] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part III -- Algorithms, Modes, and Identifiers", RFC 1115, IAB Privacy Task Force, August 1989. ]PRE] * Security Considerations [PRE[ Security issues are not addressed in this memo. ]PRE] * Authors' Addresses [PRE[ David Robinson 10-30 Prime Computer, Inc. 500 Old Connecticut Path Framingham, MA 01701 ]PRE] [PRE[ Phone: +1 508 879 2960 x1774 ]PRE] [PRE[ Email: DRB@Relay.Prime.COM ]PRE] [PRE[ Robert Ullmann 10-30 Prime Computer, Inc. 500 Old Connecticut Path Framingham, MA 01701 ]PRE] [PRE[ Phone: +1 508 879 2960 x1736 ]PRE] [PRE[ Email: Ariel@Relay.Prime.COM ]PRE] ]FIG] ** RFC 1049 → RFC 1154 [32] [[RFC 1154]] の [CSECTION[このメモの位置付け]]では > The use of Encoding updates RFC 1049 (Content-Type), and is a suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement) [4,7,8]. などと訳の分からないことをいっているが、 この当時の [[IETF]] の標準化過程ではこういうのもありだったのだろうか? ちなみに [[rfc-index.txt]] にはこれらの [[RFC]] が更新されているとか廃止されているとかいう情報はない。 (あくまで [[RFC 1154]] が[[実験的]]だからか?) [35] 「use of」なんで、 [[RFC]] という文書を[[更新]]するという [[IETF]] の正式な手続きとは違う、のかな? ** RFC 1154 → RFC 1505 [34] [[RFC 1154]] は [[RFC 1505]] で[[廃止]]されている。 [46] ただし [[RFC 1505]] の新しい [CODE(822)[[[Encoding]]:]] 欄の構文とは互換性がないし、定義されている内容もかなり違う。 * 構文 [47] 仕様が迷走していて改訂ごとにまったく違います。 ** RFC 1154 構文 [33] > The list of standard keywords is intended to be the same as the list used for the Content-Type: header described in [6]. This RFC proposes additions to the list. Implementations can then treat "Content-Type" as an alias of "Encoding", which will always have only one body part. (3.3 ) そもそも定義がこんないい加減なんで気が引けるのだが、 > [ [], ]* [] [] > where: > [PRE[ := a decimal integer := a single alphanumeric token starting with an alpha := keyword-dependent options ]PRE] [[RFC 1049]] における [CODE(822)[[[Content-Type]]:]] 欄の定義では、 [CODE[[VAR[]]]] に沿うとする部分は [CODE(char)[;]] 区切りの複数のオプションだったはずだ。 [45] まあそれは [[RFC 1154]] では違うのだとする [WEAK[([[RFC 1049]] の [CODE(822)[[[Content-Type]]]] と''構文が''同じとは別に言ってないからね)]]。 ところが、 [[RFC 1049]] の最後のオプションは [CODE(char)[,]] 区切りのリストだ! となると判断は微妙に面倒になる。 [WEAK[(この構文的に見分けるのは不可能ではないから、そう問題でないといえば問題でない。)]] ** RFC 1505 構文 [3] - [6] [CODE(ABNF)@en[[DFN[欄本体]] := *([[CFWS]] 部分欄 [[CFWS]] ",") [[CFWS]] 最後の部分欄 [[CFWS]]]] - [7] [CODE(ABNF)@en[[DFN[[RUBYB[部分欄]@en[subfield]]]] := 行数 [[CFWS]] 鍵語 *([[CFWS]] [[鍵語]])]] - [8] [CODE(ABNF)@en[[DFN[最後の[RUBYB[部分欄]@en[subfield]]]] := [行数 [[CFWS]]] 鍵語 *([[CFWS]] [[鍵語]])]] - [9] [CODE(ABNF)@en[[DFN[[RUBYB[行数]@en[count]]]] := 1*[[DIGIT]] ;; [[十進数]]]] - [10] [CODE(ABNF)@en[[DFN[[RUBYB[鍵語]@en[keyword]]]] := [[ALPHA]] *([[ALPHA]] / [[DIGIT]] / "-" / ".") ;; [[大文字]]・[[小文字]]を区別しません]] -- [15] [[英数字]]というだけで、 [CODE(charname)@en[[[HYPHEN-MINUS]]]] や [CODE(charname)@en[[[FULL STOP]]]] については明記されていません。 --[16] [CODE(ABNF)@en["X-"]] で始まる名前は実装規定の[[符号化]]用に予約されています。 --[17] その他の[[鍵語]]は [[IANA]] に登録しなければなりません。 ;; [[RFC 1505]] 2 章の規定より作成 [11] '''行数''' [[部分]]の[[行数]]を表します。 [[部分]]同士は互いに[[空行]]で区切られますが、 この[[空行]]は[[行数]]に''含みません''。 [SRC@en[RFC 1505 2.2]] [12] '''鍵語''' [[符号化]]の種類を表します。 [SRC@en[RFC 1505 2.3]] 複数指定した場合 ([DFN[[RUBYB[入れ子の鍵語]@en[nested keyword]]]]) は、多重符号化されていることを表します。 これは、単純に複数回[[符号化]]されていても構いませんし、 [[符号化]]をより詳細に説明する[[引数]]のようなものでも構いません。 [SRC@en[RFC 1505 2.3.1]] 入れ子の鍵語の順序には意味があり、 [[復号]]する際は、最初から最後の順に処理します。 [SRC@en[RFC 1505 2.3.1]] [25] '''選択肢''' [[RFC 1154]] では、[[鍵語]]は1つだけで、 その後に[[任意選択]]で[DFN[[RUBY[選択肢][せんたくし]@en[options]]]]を指定できました。 [[選択肢]]の構文は[[鍵語]]依存で、 [[読点]]は含まないとされていました。 [[RFC 1505]] との互換性はありません。 * 鍵語 [18] ,*[[鍵語]],*説明,*状態,*出典 ,[CODE(822)@en[[[EDIFACT]]]],[[EDIFACT]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[EDI]]]],[[EDI]],"[DEL[[[廃止]] ([[IETF]] [[実験的]] [[RFC]])]] → [CODE(822)@en[[[EDI-X12]]]]","[DEL@en[[[RFC 1154]]]]" ,[CODE(822)@en[[[EDI-X12]]]],[[EDI]] [[X12]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[encrypted]]]],[[PEM]],"[DEL[[[廃止]] ([[IETF]] [[実験的]] [[RFC]])]]","[DEL@en[[[RFC 1154]]]]" ,[CODE(822)@en[[[EVFU]]]],[[EVFU]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[DEL@en[[[RFC 1154]]]], [[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[FS]]]],[[ファイル・システム物体]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[Hex]]]],[[Base16]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[DEL@en[[[RFC 1154]]]], [[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[LZJU90]]]],[[LZJU90]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[LZW]]]],[[LZW]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[Message]]]],[CODE(MIME)@en[[[message/rfc822]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[DEL@en[[[RFC 1154]]]], [[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[PEM]]]],[[PEM]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[PEM-Clear]]]],[[PEM]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[PGP]]]],[[PGP]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[Postscript]]]],[CODE(MIME)@en[[[application/postscript]]]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[Shar]]]],[[シェル書庫]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[Signature]]]],[[署名]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[STARTTLS]]]],[[TLS]] 開始,"[[IETF]] [[提案標準]], [[IANAREG]]","[[IANAREG]]" ,[CODE(822)@en[[[Tar]]]],[[Tar]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[Text]]]],[CODE(MIME)@en[[[text/plain]]; [[charset]]=[[ISO-8859-1]]]],"[DEL@en[[[廃止]] ([[IETF]] [[実験的]] [[RFC]])]]","[DEL@en[[[RFC 1154]]]]" ,[CODE(822)@en[[[Text]]]],[CODE(MIME)@en[[[text/plain]]; [[charset]]=[[UTF-1]]]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[uuencode]]]],[[uuencode]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[DEL@en[[[RFC 1154]]]], [[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[URL]]]],外部 [[URL参照]],"[[IETF]] [[実験的]] [[RFC]], [[IANA]] 登録済","[[RFC 1505]], [[IANAREG]]" ,[CODE(822)@en[[[X-[VAR[*]]]]]],[[実装]]規定,"[[IETF]] [[実験的]] [[RFC]]","[DEL@en[[[RFC 1154]]]], [[RFC 1505]]" ,[CODE(822)@en[[[X.400]]]],[[X.400]],"[DEL[[[廃止]] ([[IETF]] [[実験的]] [[RFC]])]]","[DEL@en[[[RFC 1154]]]]" [23] [CODE(822)@en[[[STARTTLS]]]] は明らかに誤りだと思いますが・・・・・・。 [[RFC 2487]] にはまったく言及がありませんし・・・・・・。 [28] >>23 いつの間にか削除されているようです。 [TIME[2015-06-10T15:03:10.100Z]] [24] [CODE(822)@en[[[Encoding]]:]] [[頭欄]]がない場合の既定値は [CODE(822)@en[[[Text]]]] です。 [SRC@en[RFC 1154 2, RFC 1505 1]] [[#comment]] ** 実装 [1] [CODE(822)[Encoding]] 欄について [[Ned]] が Re: Mail/MIME permanent header registrations (2004年4月) で書いているところによると: - 行数じゃなくてバイト数を数えてる MUA がある。 - ファイル名を埋め込む MUA がある。 - 入れ子とか、 [[RFC 1505]] にある型の多くは、対応しているのが稀。 - 行数にせよバイト数にせよ、転送中に行折畳みとかタブ展開とか charset 変換とかがあると壊れる。 ([[名無しさん]] [WEAK[2004-04-20 08:34:45 +00:00]]) [2] というかむしろ、相互運用性に問題が出るほど実装があったということ自体驚き。 ([[名無しさん]] [WEAK[2004-04-20 08:35:26 +00:00]]) [22] [[行数]]の指定と実際の[[本体]]の長さに齟齬があったら? [REFS[ - [2] [CITE@en[RFC 1505 - Encoding Header Field for Internet Messages]] ([TIME[2014-02-23 03:15:51 +09:00]] 版) ]REFS] *現代からみた RFC 1505 [39] [[RFC1154]]の後継。 [[RFC1049]]の子孫(?)。 [[MIME]] の対抗馬(?)。 RFC 1154 と同じく [[Encoding:領域]]を定義するけど、 あんまり互換性があるようには見えんぞ。 [40] [[RFC1505の日付形式]]を定義。[[RFC822の日付形式]] に秒未満を6桁分まで確保。 [41] TEXT 型はなんと [[UTF-1]]。 UTF-1 って ASCII の上位互換だっけ? MIME より人可読性を優先してるような。そういう面では MIME の方が 遥かに先進的。 MIME も色々アレだけど、 Encoding: 領域よりは MIME で良かったかも。 [42] [TIME[2002-12-21 20:36]] ''[[名無しさん]]'': [[rfc-ibdex]] では Status: Experimental ですが、 [[IETF]] Application Area Director は Histrical にしようと考えています。 (''Candidates for Historic status'' ) [43] >>42 未だに [[Historic]] ではなく [[Experimetnal]] のままのようです。 [[IETF]] は一旦 [[RFC]] として発行した後は実装されようがされまいが放置することが多いですね。 [TIME[2015-10-24T11:38:29.800Z]] [44] 未だにそのままみたいですね。 [TIME[2021-03-14T03:10:18.800Z]] * 関連 [26] [[RFC 1154]] は [[RFC 1049]] の [CODE(822)@en[[[Content-Type]]:]] [[頭欄]]の置き換えを狙っていました (という記述は [[RFC 1505]] からはなくなっています)。 [[鍵語]]は [[RFC 1049]] と同じものが使えるので、 [[実装]]は [CODE(822)@en[[[Content-Type]]:]] を [CODE(822)@en[[[Encoding]]:]] の別名として使えると主張されています [SRC@en[RFC 1154 3.3]]。 しかし、実際には [[RFC 1049]] と [[RFC 1154]] で規定されている[[鍵語]]は中心部分が重なるだけで異なる[[集合]]ですし、 そもそも両者の構文も中核部分が一致するだけで互換性がありません。 [[#comment]] ** 例 [13] [SRC@en[RFC 1505 2.3]] [PRE(822 old example code)[ Encoding: 107 Text ]PRE] [14] 入れ子の鍵語の例 [SRC@en[RFC 1505 2.3.1]] [PRE(822 old example code)[ Encoding: 458 uuencode LZW tar [SPAN(comment)[(Unix binary object)]] ]PRE] これは、もとのデータが [[tar]] で[[書庫]]化され、 [[LZW]] で[[圧縮]]され、更に [[uuencode]] された状態で[[部分]]として458行分含まれていることを表します。 * メモ