/[pub]/suikawiki/sw4data/ids/8/137.txt
Suika

Contents of /suikawiki/sw4data/ids/8/137.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (hide annotations) (download)
Sat Nov 15 21:47:56 2008 UTC (16 years, 7 months ago) by wakaba
Branch: MAIN
CVS Tags: before-graph-20090923, suika-20100509, HEAD
File MIME type: text/plain
converted from SuikaWiki3 <http://suika.fam.cx/gate/cvs/suikawiki/wikidata/page/C6E2CDC6C0DEBED7.ns/BBC5CDCDBDF1.txt>

1 wakaba 1.1 #?SuikaWiki/0.9
2     *電子メイル : エージェント駆動内容折衝
3     :[[RFC1341]] 『MIME (Multipurpose Internet Mail Extensions) - Mechanisms for Specifying and Describing the Format of Internet Message Bodies』, N. Borenstein, N. Freed, 1992年6月。 (Obsoleted by RFC 1521) (PROPOSED STANDARD):
4     :[[RFC1521]] 『MIME (Multipurpose Internet Mail Extensions) Part One - Mechanisms for Specifying and Describing the Format of Internet Message Bodies』, N. Borenstein, N. Freed, 1993年9月。 (Obsoletes RFC 1341) (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) (Updated by RFC 1590) (DRAFT STANDARD):
5     :[[RFC2046]] 『Multipurpose Internet Mail Extensions (MIME) Part Two - Media Types』, N. Freed, N. Borenstein, 1996年11月。 (Obsoletes RFC 1521, RFC 1522, RFC 1590) (Updated by RFC 2646) (DRAFT STANDARD):
6     [[MIME]] は [CODE(MIME)[[[multipart/alternative]]]] という、予め送られた複数の選択肢から MUA 側で適当なものを選択する仕組みが用意されていました。
7     普通はすべての選択肢を送らなければなりませんが、
8     [CODE(MIME)[[[message/external-body]]]] と組合せれば選択したものだけを取り寄せさせることも可能です。
9    
10     * HTTP : サーバー駆動内容折衝
11     :[[RFC1945]] 『Hypertext Transfer Protocol -- HTTP/1.0』, T. Berners-Lee, R. Fielding, H. Frystyk, 1996年5月。 (INFORMATIONAL):
12     参考として Accept‐ 頭群が使用されていることに触れられていました。
13     :[[RFC2068]] 『Hypertext Transfer Protocol -- HTTP/1.1』, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, 1997年1月。 (Obsoleted by RFC 2616) (PROPOSED STANDARD):
14     Accept‐ 頭群を初めて厳格に定義し、内容折衝の基本的な概念を規定しました。
15     基本的にはサーバー駆動折衝だけしか定義していませんが、
16     クライアント駆動折衝・透過折衝の準備的な規定が少々あります。
17     :[[RFC2616]] 『Hypertext Transfer Protocol -- HTTP/1.1』, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, 1999年6月。(Obsoletes RFC 2068) (Updated by RFC 2817) (DRAFT STANDARD):
18     RFC 2068 の新版で、内容折衝に関してはほぼ同じ内容ですが、
19     [CODE(HTTP)[[[Alternates]]]] 欄の紹介は削除されてしまっています。
20    
21     * HTTP : 透過内容折衝
22     :[[RFC2295]] 『Transparent Content Negotiation in HTTP』, K. Holtman, A. Mutz, 1998年3月。 (EXPERIMENTAL):
23     HTTP 本体の RFC では未規定で残されていた透過内容折衝を具体的に規定しています。
24     :[[RFC2296]] 『HTTP Remote Variant Selection Algorithm -- RVSA/1.0』, K. Holtman, A. Mutz, 1998年3月。 (EXPERIMENTAL):
25     透過内容折衝のための構文的な仕組みを定義したのが RFC 2295 で、
26     それとセットで使う標準化された[[変種]]選択のための算法が RFC 2296 で規定されています。
27    
28     * 電子メイル : 透過内容折衝
29     :[[RFC2703]] 『Protocol-independent Content Negotiation Framework』, G. Klyne, 1999年9月。 (INFORMATIONAL):
30     ファックスの取込み等々から内容折衝は電子メイル界でも必要とされることとなりまして、
31     HTTP と電子メイル共通の内容折衝の枠組みを定めたのがこの RFC です。
32     :[[RFC2530]] 『Indicating Supported Media Features Using Extensions to DSN and MDN』, D. Wing, 1999年3月。 (PROPOSED STANDARD):
33     電子メイルの内容折衝で伝令の役目を果たすのが [[DSN]] と [[MDN]]。
34     その中で特徴を記述する方法の規格。
35     :[[RFC2912]] 『Indicating Media Features for MIME Content』, G. Klyne, 2000年9月。 (PROPOSED STANDARD):
36     電子メイルで特徴を記述する方法の規格。
37     :[[RFC3297]] 『Content Negotiation for Messaging Services based on Email』, G. Klyne, R. Iwazaki, D. Crocker』, 2002年7月。 (PROPOSED STANDARD):
38     実際に内容折衝を使うための電子メイルのプロトコル要素と折衝手続きを規定したのがこちらの RFC。
39    
40     * 特徴札
41     :[[RFC2506]] 『Media Feature Tag Registration Procedure』, K. Holtman, A. Mutz, T. Hardie, 1999年3月。 (Also [[BCP0031]]) (BEST CURRENT PRACTICE):
42     内容折衝で対応している機能や利用者の好みを記述するための[[特徴札]]。
43     その標準化された名前を管理する手続きを定める RFC。
44     :[[RFC2531]] 『Content Feature Schema for Internet Fax』, G. Klyne, L. McIntyre, 1999年3月。 (Obsoleted by RFC 2879) (PROPOSED STANDARD):
45     ファックスの特徴を記述するための種々の特徴札の定義とその用例。
46     :[[RFC2533]] 『A Syntax for Describing Media Feature Sets』, G. Klyne, 1999年3月。 (Updated by RFC 2738, RFC 2938) (PROPOSED STANDARD):
47     [[特徴集合]]の記述のための構文を定義する RFC。
48     :[[RFC2534]] 『Media Features for Display, Print, and Fax』, L. Masinter, D. Wing, A. Mutz, K. Holtman, 1999年3月。 (PROPOSED STANDARD):
49     画面, 印刷, ファックスの3種の表示媒体の特徴の記述について。
50     :[[RFC2738]] 『Corrections to "A Syntax for Describing Media Feature Sets"』, G. Klyne, 1999年12月。 (Updates RFC 2533) (PROPOSED STANDARD):
51     RFC 2533 の虫取り。
52     :[[RFC2879]] 『Content Feature Schema for Internet Fax (V2)』, G. Klyne, L. McIntyre, 2000年8月。 (Obsoletes RFC 2531) (PROPOSED STANDARD):
53     RFC 2531 の改訂。ファックスのための特徴。
54     :[[RFC2880]] 『Internet Fax T.30 Feature Mapping』, L. McIntyre, G. Klyne, 2000年8月。 (INFORMATIONAL):
55     T.30 との特徴写像。
56     :[[RFC2913]] 『MIME Content Types in Media Feature Expressions』, G. Klyne, 2000年9月。 (PROPOSED STANDARD):
57     特徴としての[[媒体型]]の記述。
58     :[[RFC2938]] 『Identifying Composite Media Features』, G. Klyne, L. Masinter, 2000年9月。 (Updates RFC 2533) (PROPOSED STANDARD):
59     複合的な場合の特徴の記述。
60     :[[RFC2987]] 『Registration of Charset and Languages Media Features Tags』, P. Hoffman, 2000年11月。 (PROPOSED STANDARD):
61     特徴としての [[charset]] と[[言語]]の記述。
62    
63     * メモ
64     - [1] [[RFC2326]] : [[RTSP]] は [[Accept‐頭欄]]を用意していますが、仕様は HTTP 参照であって取り立てて内容折衝に触れてはいません。[WEAK[内容折衝とは無関係のプロトコル内の転送の折衝の仕組みが別にあります。]]
65     - [2] >>1 [[SIP]] も似たような状況です。RTSP や SIP は HTTP 派生プロトコルと入っても扱う「内容」が随分異なりますからそんなもんでしょうね。
66     - [3] >>1-2 RTSP や SIP では HTTP の [[Accept‐頭群]]と同じものがおまけでついてくるくらいに考えた方がいいかも。

admin@suikawiki.org
ViewVC Help
Powered by ViewVC 1.1.24