RFC2369 日本語訳
2369 The Use of URLs as Meta-Syntax for Core Mail List Commands andtheir Transport through Message Header Fields. G. Neufeld, J. Baer. July 1998. (Format: TXT=30853 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Neufeld
Request for Comments: 2369 Nisto
Category: Standards Track J. Baer
SkyWeyr Technologies
July 1998
コメントを求めるワーキンググループG.ニューフェルド要求をネットワークでつないでください: 2369年のNistoカテゴリ: 標準化過程J.ベヤーSkyWeyr技術1998年7月
The Use of URLs as Meta-Syntax for Core Mail List Commands
and their Transport through Message Header Fields
CoreメールList CommandsとMessage Headerフィールズを通した彼らのTransportのためのMeta-構文としてのURLのUse
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。
Abstract
要約
The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists. Each field typically contains a URL (usually mailto [RFC2368]) locating the relevant information or performing the command directly. The three core header fields described in this document are List-Help, List-Subscribe, and List-Unsubscribe.
メーリングリストコマンド仕様ヘッダーフィールドは1セットのメール発送先リストによって送られたメッセージをメールするために加えられるべき構造化された分野です。 各分野は、関連情報の場所を見つけるか、または直接コマンドを実行しながら、URL(通常mailto[RFC2368])を通常含んでいます。 本書では説明された3つのコアヘッダーフィールドが、List-ヘルプ、List申し込んで、List外します。
There are three other header fields described here which, although not as widely applicable, will have utility for a sufficient number of mailing lists to justify their formalization here. These are List-Post, List-Owner and List-Archive.
同じくらい広く適切ではありませんが、メーリングリストのここで彼らの形式化を正当化できるくらいの数のためのユーティリティを持っているここで説明された他の3つのヘッダーフィールドがあります。 これらは、List-ポストと、List-所有者とList-アーカイブです。
By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions. This could take the form of a menu item, push button, or other user interface element. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands.
これらのヘッダーフィールドを含んでいることによって、リストサーバでユーザがリスト機能を実行するようにメールクライアントが自動化されたツールを提供するのが可能になる場合があります。 これはメニュー項目、押しボタン、または他のユーザーインタフェース要素の形を取るかもしれません。 意図はユーザー・エクスペリエンスを簡素化することです、しばしば不可解で様々なメーリングリストマネージャコマンドに一般的なインタフェースを提供して。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
Neufeld & Baer Standards Track [Page 1] RFC 2369 URLs as Meta-Syntax July 1998
ニューフェルドとベヤーStandardsはメタ構文1998年7月としてRFC2369URLを追跡します[1ページ]。
1. Introduction
1. 序論
This is a proposal for additional header fields to be added to email messages sent by email distribution lists. The content of each new field is typically a URL - usually mailto [RFC2368] - which locates the relevant information or performs the command directly. MTAs generating the header fields SHOULD usually include a mailto based command, in addition to any other protocols used, in order to support users who do not have access to non-mail-based protocols.
これは追加ヘッダーフィールドがメール発送先リストによって送られたメッセージをメールするために加えられるという提案です。 通常、それぞれの新しい分野の内容は関連情報の場所を見つけるか、または直接コマンドを実行するURL(通常mailto[RFC2368])です。 通常、ヘッダーフィールドがSHOULDであると生成するMTAsがmailtoのベースのコマンドを含んでいます、非メールベースのプロトコルに近づく手段を持っていないユーザをサポートするのに使用されるいかなる他のプロトコルに加えて。
Implementing these fields will be optional. Significant functionality and convenience can be gained by including them, however. Many list managers, especially as the proposal first gains acceptance, MAY choose to implement only one or two of the fields. The List-Help field is the most useful individual field since it provides an access point to detailed user support information, and accommodates almost all existing list managers command sets. The List-Subscribe and List-Unsubscribe fields are also very useful, but cannot describe some list manager syntaxes at this time (those which require variable substitution). See appendix A.5 for an explanation.
これらの分野を実装するのは任意でしょう。 しかしながら、それらを含んでいることによって、重要な機能性と便利を獲得できます。特に提案が最初に承認を獲得するように多くのリストマネージャが、1か2つの分野だけを実装するのを選ぶかもしれません。 詳細なユーザ・サポート情報にアクセスポイントを提供して、ほとんどすべての既存のリストマネージャコマンドセットを収容して以来、List-ヘルプ、分野は最も役に立つ個々の分野です。 List申し込んでいてList外している分野は、また、非常に役に立ちますが、このとき、いくつかのリストマネージャ構文について説明できません(可変代替を必要とするもの)。 説明に関して付録A.5を見てください。
The description of command syntax provided by the fields can be used by mail client applications to provide simplified and consistent user access to email distribution list functions. This could take the form of menu items, push buttons, or other user interface elements. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands.
発送先リスト機能をメールするために簡易型の、そして、一貫したユーザアクセスを提供するのにメールクライアントアプリケーションで分野によって提供されたコマンド構文の記述を使用できます。 これはメニュー項目、押しボタン、または他のユーザーインタフェース要素の形を取るかもしれません。 意図はユーザー・エクスペリエンスを簡素化することです、しばしば不可解で様々なメーリングリストマネージャコマンドに一般的なインタフェースを提供して。
Consideration has been given to avoiding the creation of too many fields, while at the same time avoiding the overloading of individual fields and keeping the syntax clear and simple.
同時に、個々の分野の積みすぎを避けて、明確で簡単に構文を保っている間、あまりに多くの分野の作成を避けることに対して考慮を払っています。
The use of these fields does not remove the requirement to support the -Request command address for mailing lists [RFC2142].
これらの分野の使用は要求コマンドがメーリングリスト[RFC2142]のためのアドレスであるとサポートするという要件を取り除きません。
2. The Command Syntax
2. コマンド構文
The list header fields are subject to the encoding and character restrictions for mail headers as described in [RFC822]. Additionally, the URL content is further restricted to the set of URL safe characters [RFC1738].
リストヘッダーフィールドは[RFC822]で説明されるようにメールヘッダのためのコード化とキャラクタ制限を受けることがあります。 さらに、URL内容はさらにURLの安全なキャラクタ[RFC1738]のセットに制限されます。
The contents of the list header fields mostly consist of angle-
bracket ('<', '>') enclosed URLs, with internal whitespace being
ignored. MTAs MUST NOT insert whitespace within the brackets, but
client applications should treat any whitespace, that might be
inserted by poorly behaved MTAs, as characters to ignore.
リストヘッダーフィールドの内容は角度ブラケット同封の('<'、'>')URLからほとんど成ります、内部の空白が無視されている状態で。 クライアントアプリケーションはどんな空白も扱うべきです、そして、MTAsは括弧の中で空白を挿入してはいけませんが、それは不十分に振る舞っているMTAsによって挿入されるかもしれません、無視するキャラクタとして。
Neufeld & Baer Standards Track [Page 2] RFC 2369 URLs as Meta-Syntax July 1998
ニューフェルドとベヤーStandardsはメタ構文1998年7月としてRFC2369URLを追跡します[2ページ]。
A list of multiple, alternate, URLs MAY be specified by a comma- separated list of angle-bracket enclosed URLs. The URLs have order of preference from left to right. The client application should use the left most protocol that it supports, or knows how to access by a separate application. By this mechanism, protocols like http may be specified while still providing the basic mailto support for those clients who do not have access to non-mail protocols. The client should only use one of the available URLs for a command, using another only if the first one used failed.
複数の、そして、代替のURLのリストは角ブラケットの同封のURLのコンマの切り離されたリストによって指定されるかもしれません。 URLには、左から右までよく使われる順があります。 クライアントアプリケーションは大部分が議定書の中で述べる左を使用するべきです。それは、別々のアプリケーションでその方法をアクセスにサポートするか、または知っています。 このメカニズムで、httpのようなプロトコルはまだ非メールプロトコルに近づく手段を持っていないクライアントの基本的なmailtoサポートを提供している間、指定されるかもしれません。 クライアントはコマンドに利用可能なURLの1つを使用するだけであるべきです、1つが使用した1番目が失敗した場合にだけ別のものを使用して。
The use of URLs allows for the use of the syntax with existing URL supporting applications. As the standard for URLs is extended, the list header fields will gain the benefit of those extensions. Additionally, the use of URLs provides access to multiple transport protocols (such as ftp and http) although it is expected that the "mailto" protocol [RFC2368] will be the focus of most use of the list header fields. Use of non-mailto protocols should be considered in light of those users who do not have access to the specified mechanism (those who only have email - with no web access).
URLの使用は構文の存在する使用のためにアプリケーションをサポートするURLを許容します。 URLの規格が拡張されているのに従って、リストヘッダーフィールドはそれらの拡大の恩恵を獲得するでしょう。 さらに、"mailto"プロトコル[RFC2368]がリストヘッダーフィールドのほとんどの使用の焦点になると予想されますが、URLの使用は複数のトランスポート・プロトコル(ftpやhttpなどの)へのアクセスを提供します。 非mailtoプロトコルの使用は指定されたメカニズム(ウェブアクセスなしでメールを持っているだけである人)に近づく手段を持っていないユーザの観点から考えられるべきです。
Command syntaxes requiring variable fields to be set by the client (such as including the user's email address within a command) are not supported by this implementation. However, systems using such syntaxes SHOULD still take advantage of the List-Help field to provide the user with detailed instructions as needed or - perhaps more usefully - provide access to some form of structured command interface such as an HTML-based form.
変数フィールドがクライアント(コマンドの中にユーザのEメールアドレスを含むことなどの)によって設定されるのを必要とするコマンド構文がこの実装によってサポートされません。 または、しかしながら、そのような構文SHOULDを使用するシステムが必要に応じて細かい指示をユーザに提供するのにまだList-ヘルプ、分野を利用している、--恐らくより有効に、何らかのフォームのHTMLベースのフォームなどの構造化されたコマンドインタフェースへのアクセスを提供してください。
The additional complications of supporting variable fields within the command syntax was determined to be too difficult to support by this protocol and would compromise the likelihood of implementation by software authors.
コマンド構文の中で可変分野をサポートする追加複雑さは、このプロトコルでサポートすることができないくらい難しいと決心していて、ソフトウェア作者で実装の見込みに感染するでしょう。
To allow for future extension, client applications MUST follow the following guidelines for handling the contents of the header fields described in this document:
今後の拡大を考慮するために、クライアントアプリケーションはヘッダーフィールドのコンテンツが本書では説明した取り扱いのための以下のガイドラインに従わなければなりません:
1) Except where noted for specific fields, if the content of the
field (following any leading whitespace, including comments)
begins with any character other than the opening angle bracket
'<', the field SHOULD be ignored.
1) 分野(コメントを含むどんな主な空白にも続く)の内容がどんなキャラクタと共にも始まるなら初めの角ブラケット'<'、分野SHOULDを除いて、特定の分野で有名であるのを除いて、無視されてください。
2) Any characters following an angle bracket enclosed URL SHOULD be
ignored, unless a comma is the first non-whitespace/comment
character after the closing angle bracket.
2) 角ブラケットの同封のURL SHOULDの後をつけるどんなキャラクタも無視されて、コンマが最初の非空白/でないなら終わりの角ブラケットの後にキャラクタについて論評してください。
Neufeld & Baer Standards Track [Page 3] RFC 2369 URLs as Meta-Syntax July 1998
ニューフェルドとベヤーStandardsはメタ構文1998年7月としてRFC2369URLを追跡します[3ページ]。
3) If a sub-item (comma-separated item) within the field is not an
angle-bracket enclosed URL, the remainder of the field (the
current, and all subsequent, sub-items) SHOULD be ignored.
3) 分野の中のサブ項目(コンマで切り離された項目)がそうでないなら、角ブラケットはURLを同封しました、分野(現在の、そして、その後のサブ項目)の残り SHOULD、無視されてください。
3. The List Header Fields
3. リストヘッダーフィールド
This document presents header fields which will provide the
command syntax description for the 'core' and key secondary
functions of most email distribution lists. The fields implemented
on a given list SHOULD be included on all messages distributed by
the list (including command responses to individual users), and on
other messages where the message clearly applies to one distinct
list. There MUST be no more than one of each field present in any
given message.
このドキュメントは'コア'のためのコマンド構文記述を提供するヘッダーフィールドとほとんどのメール発送先リストの主要な二次的な機能を提示します。 含まれていて、与えられたリストSHOULDで実装された分野はリスト(個々のユーザへのコマンド応答を含んでいる)の近くと、そして、他上ですべてのメッセージでメッセージが明確に1つの異なったリストに適用されるメッセージを分配しました。 どんな与えられたメッセージの現在のそれぞれの分野の1つ未満もあるに違いありません。
These fields MUST only be generated by mailing lists, not end
users.
エンドユーザではなく、メーリングリストでこれらの分野を生成するだけでよいです。
3.1. List-Help
3.1. リストヘルプ
The List-Help field is the most important of the header fields
described in this document. It would be acceptable for a list
manager to include only this field, since by definition it SHOULD
direct the user to complete instructions for all other commands.
Typically, the URL specified would request the help file, perhaps
incorporating an HTML form for list commands, for the list, and
alternatively provide access to an instructive website.
本書では説明されたヘッダーフィールドでList-ヘルプ、分野は最も重要です。 リストマネージャが以来定義上この分野だけを入れるのが、許容できるだろう、それ、SHOULDは、他のすべてのコマンドのための指示を終了するようユーザに指示します。 指定されたURLは、通常、ヘルプファイル、恐らくHTMLフォーム繰返し要素の並びがリストのために命令する盛込むのを要求して、あるいはまた、ためになったウェブサイトへのアクセスを提供するでしょう。
Examples:
例:
List-Help: <mailto:list@host.com?subject=help> (List Instructions)
List-Help: <mailto:list-manager@host.com?body=info>
List-Help: <mailto:list-info@host.com> (Info about the list)
List-Help: <http://www.host.com/list/>, <mailto:list-info@host.com>
List-Help: <ftp://ftp.host.com/list.txt> (FTP),
<mailto:list@host.com?subject=help>
リストヘルプ: <mailto: list@host.com?subject =助け>(リスト指示)リストヘルプ: <mailto: list-manager@host.com?body がインフォメーションと等しい、gt;、リストヘルプ: <mailto: list-info@host.com 、gt;、(リストに関するインフォメーション) リストヘルプ: <mailto: <http://www.host.com/list/>、 list-info@host.com 、gt;、リストヘルプ: <ftp://ftp.host.com/list.txt>(FTP)、<mailto: list@host.com?subject は助け>と等しいです。
3.2. List-Unsubscribe
3.2. リストで外してください。
The List-Unsubscribe field describes the command (preferably using mail) to directly unsubscribe the user (removing them from the list).
List外している分野は直接ユーザを外すコマンド(望ましくは、メールを使用する)について説明します(リストからそれらを取り除いて)。
Examples:
例:
List-Unsubscribe: <mailto:list@host.com?subject=unsubscribe>
List-Unsubscribe: (Use this command to get off the list)
<mailto:list-manager@host.com?body=unsubscribe%20list>
List-Unsubscribe: <mailto:list-off@host.com>
リストで外してください: <mailto: list@host.com?subject =はリストで外した状態で>を外します: (リストを離すこのコマンドを使用します) <mailto: list-manager@host.com?body =はリストで外した状態で%20list>を外します: <mailto: list-off@host.com 、gt。
Neufeld & Baer Standards Track [Page 4] RFC 2369 URLs as Meta-Syntax July 1998
ニューフェルドとベヤーStandardsはメタ構文1998年7月としてRFC2369URLを追跡します[4ページ]。
List-Unsubscribe: <http://www.host.com/list.cgi?cmd=unsub&lst=list>,
<mailto:list-request@host.com?subject=unsubscribe>
リストで外してください: <http://www.host.com/list.cgi?<mailto: cmd=unsubとlst=リスト>、 list-request@host.com?subject =は>を外します。
3.3. List-Subscribe
3.3. リストで申し込んでください。
The List-Subscribe field describes the command (preferably using mail) to directly subscribe the user (request addition to the list).
List申し込んでいる分野は直接ユーザを申し込むコマンド(望ましくは、メールを使用する)について説明します(リストに追加を要求してください)。
Examples:
例:
List-Subscribe: <mailto:list@host.com?subject=subscribe>
List-Subscribe: <mailto:list-request@host.com?subject=subscribe>
List-Subscribe: (Use this command to join the list)
<mailto:list-manager@host.com?body=subscribe%20list>
List-Subscribe: <mailto:list-on@host.com>
List-Subscribe: <http://www.host.com/list.cgi?cmd=sub&lst=list>,
<mailto:list-manager@host.com?body=subscribe%20list>
リストで申し込んでください: <mailto: list@host.com?subject =はリストで申し込んだ状態で>を申し込みます: <mailto: list-request@host.com?subject =が申し込まれる、gt;、リストで申し込んでください: (リストを接合するこのコマンドを使用します) <mailto: list-manager@host.com?body =はリストで申し込んだ状態で%20list>を申し込みます: <mailto: list-on@host.com 、gt;、リストで申し込んでください: <http://www.host.com/list.cgi?<mailto: cmd=潜水艦とlst=リスト>、 list-manager@host.com?body =は%20list>を申し込みます。
3.4. List-Post
3.4. リストポスト
The List-Post field describes the method for posting to the list. This is typically the address of the list, but MAY be a moderator, or potentially some other form of submission. For the special case of a list that does not allow posting (e.g., an announcements list), the List-Post field may contain the special value "NO".
List-ポスト分野は任命のためのメソッドをリストに説明します。 通常、これは議長、または潜在的にある他の形式の服従であるかもしれないこと以外のリストのアドレスです。 (例えば、発表リスト)を掲示させないリストの特別なケースのために、List-ポスト分野は特別な値の「いいえ」を含むかもしれません。
Examples:
例:
List-Post: <mailto:list@host.com>
List-Post: <mailto:moderator@host.com> (Postings are Moderated)
List-Post: <mailto:moderator@host.com?subject=list%20posting>
List-Post: NO (posting not allowed on this list)
リストポスト: <mailto: list@host.com 、gt;、リストポスト: <mailto: moderator@host.com 、gt;、(任命はModeratedです) リストポスト: <mailto: moderator@host.com?subject は%20posting>がリストで掲示するリストと等しいです: いいえ(このリストで許されなかった任命)
3.5. List-Owner
3.5. リスト所有者
The List-Owner field identifies the path to contact a human administrator for the list. The URL MAY contain the address of a administrator for the list, the mail system administrator, or any other person who can handle user contact for the list. There is no need to specify List-Owner if it is the same person as the mail system administrator (postmaster).
List-所有者分野は、リストのために人間の管理者に連絡するために経路を特定します。 URLはリスト、メールシステム管理者、またはいかなる他の人のためのリストのためにユーザ接触を扱うことができる管理者のアドレスも含むかもしれません。 List-所有者を指定する必要はそれがメールシステム管理者(郵便局長)と同じ人であるなら全くありません。
Examples:
例:
List-Owner: <mailto:listmom@host.com> (Contact Person for Help)
List-Owner: <mailto:grant@foo.bar> (Grant Neufeld)
List-Owner: <mailto:josh@foo.bar?Subject=list>
リスト所有者: <mailto: listmom@host.com 、gt;、(ヘルプを求める連絡窓口)リスト所有者: <mailto: grant@foo.bar 、gt;、(Grantニューフェルド)リスト所有者: <mailto: josh@foo.bar?Subject はリスト>と等しいです。
Neufeld & Baer Standards Track [Page 5] RFC 2369 URLs as Meta-Syntax July 1998
ニューフェルドとベヤーStandardsはメタ構文1998年7月としてRFC2369URLを追跡します[5ページ]。
3.6. List-Archive
3.6. リストアーカイブ
The List-Archive field describes how to access archives for the list.
List-アーカイブ分野はリストのためのアーカイブにアクセスする方法を説明します。
Examples:
例:
List-Archive: <mailto:archive@host.com?subject=index%20list>
List-Archive: <ftp://ftp.host.com/pub/list/archive/>
List-Archive: <http://www.host.com/list/archive/> (Web Archive)
リストアーカイブ: <mailto: archive@host.com?subject は%20list>がリストで格納するインデックスと等しいです: <ftp://ftp.host.com/pub/list/archive/>リストアーカイブ: <http://www.host.com/list/archive/>。(ウェブ・アーカイブ)
4. Supporting Nested Lists
4. 入れ子にされたリストをサポートします。
A list that is a sublist for another list in a nested mailing list hierarchy will need to modify some of the List- header fields, while leaving others as the parent list set them.
入れ子にされたメーリングリスト階層構造の別のリストのためのサブリストであるリストは、親リストが彼らを設定しながら他のものを残す間、Listヘッダーフィールドのいくつかを変更する必要があるでしょう。
Sublists SHOULD remove the parent list's List-Help, List-Subscribe, List-Unsubscribe and List-Owner fields, and SHOULD insert their own versions of those fields.
サブリストSHOULDはList申し込んでいて、List外しているList-ヘルプと親リストのList-所有者野原を取り除きます、そして、SHOULDはそれら自身のそれらの分野のバージョンを挿入します。
If the sublist provides its own archive, it SHOULD replace the List- Archive with its own. Otherwise, it MUST leave the List-Archive field untouched.
サブリストはそれ自身のアーカイブを提供して、それはSHOULDです。Listアーカイブをそれ自身のものに取り替えてください。 さもなければ、それは触れない状態でList-アーカイブ野原を出なければなりません。
Dependant on how postings to the list are handled, the sublist MAY replace the List-Post field. The appropriateness of whether to replace List-Post is left to the determination of the individual list managers. If the intention is that postings should be distributed to all members of the primary list, List-Post should not be changed by a sublist in such a way that postings will be distributed only to members of the sublist.
リストへの任命がどうあるかの扶養家族が扱われて、サブリストはList-ポスト野原を取り替えるかもしれません。 List-ポストを取り替えるかどうかに関する適切さは個々のリストマネージャの決断に残されます。 意志が任命がプライマリリストのすべてのメンバーに広げられるべきであるということであるなら、サブリストは任命がサブリストのメンバーだけに広げられるような方法でList-ポストを変えるべきではありません。
5. Security Considerations
5. セキュリティ問題
There are very few new security concerns generated with this proposal. Message headers are an existing standard, designed to easily accommodate new types. There may be concern with multiple fields being inserted or headers being forged, but these are problems inherent in Internet email, not specific to the protocol described in this document. Further, the implications are relatively harmless.
この提案で生成されたほんのわずかな新しい安全上の配慮があります。 メッセージヘッダーは容易に新しいタイプに対応するように設計された既存の規格です。 複数の野原が挿入されていて、ヘッダーが鍛造されているので、関心があるかもしれませんが、これらは本書では説明されたプロトコルに特定であるのではなく、インターネットメールの固有である問題です。 さらに、含意は比較的無害です。
Mail list processors should not allow any user-originated list header fields to pass through to their lists, lest they confuse the user and have the potential to create security problems.
少しのユーザによって溯源されたリストヘッダーフィールドもメール・リストプロセッサでそれらのリストに通り抜けるべきではありません、ユーザを混乱させて、警備上の問題を作成する可能性を持っているといけないので。
On the client side, there may be some concern with posts or commands being sent in error. It is required that the user have a chance to confirm any action before it is executed. In the case of mailto, it
クライアント側に、ポストかコマンドを間違って送る何らかの関心があるかもしれません。 ユーザにはそれが実行される前にどんな動作も確認する機会があるのが必要です。 mailtoの場合でそれ
Neufeld & Baer Standards Track [Page 6] RFC 2369 URLs as Meta-Syntax July 1998
ニューフェルドとベヤーStandardsはメタ構文1998年7月としてRFC2369URLを追跡します[6ページ]。
may be appropriate to create the correctly formatted message without sending it, allowing the user to see exactly what is happening and giving the user the opportunity to approve or discard the message before it is sent.
それを送らないで正しくフォーマットされたメッセージを作成するのは適切であるかもしれません、ユーザが、それを送る前に、まさに何が起こって、メッセージを承認するか、または捨てる機会をユーザに与えているかを見るのを許容して。
All security considerations for the use of URLs [RFC1738] apply equally to this protocol. Mail client applications should not support list header field URLs which could compromise the security of the user's system. This includes the "file://" URL type which could potentially be used to trigger the execution of a local application on some user systems.
URL[RFC1738]の使用のためのすべてのセキュリティ問題が等しくこのプロトコルに適用されます。 メールクライアントアプリケーションは、リストヘッダーフィールドがユーザのシステムのセキュリティに感染することができたURLであるとサポートするべきではありません。 これはいくつかのユーザシステムにおける局所塗布の実行の引き金となるのに潜在的に使用できた「ファイル://」URLタイプを含んでいます。
6. Acknowledgements
6. 承認
The numerous participants of the List-Header [5], ListMom-Talk [6], List-Managers and MIDA-Mail mailing lists contributed much to the formation and structure of this document.
List-ヘッダー[5]、ListMom-話の[6]、List-マネージャ、およびMIDA-メールメーリングリストの多数の関係者はこのドキュメントの構成と構造にかなり貢献しました。
Keith Moore <moore@cs.utk.edu> and Christopher Allen <ChristopherA@consensus.com> provided guidance on the standards process.
キース Moore <moore@cs.utk.edu 、gt;、クリストファー Allen <ChristopherA@consensus.com 、gt;、標準化過程で指導を提供しました。
Neufeld & Baer Standards Track [Page 7] RFC 2369 URLs as Meta-Syntax July 1998
ニューフェルドとベヤーStandardsはメタ構文1998年7月としてRFC2369URLを追跡します[7ページ]。
A. Background Discussion
A。 バックグラウンド議論
This proposal arose from discussions started on the ListMom-Talk Discussion List [6]. When the discussion reached a sufficient level, a separate list was formed for discussing this proposal, the List Headers Mail List [5] for deeper discussion. We have included summaries of key issues raised, in order to show some of the alternatives examined and reasons for our decisions.
この提案はListMom-話のディスカッション・リスト[6]に始められた議論から起こりました。 議論が十分なレベルに達したとき、別々のリストは、この提案(より深い議論のためのList HeadersメールList[5])について議論するために形成されました。 私たちは代替手段について何かが私たちの決定のために調べて、推論したのを示すために提起される主要な問題の概要を入れました。
A.1. Multiple header fields vs. a single header field
A.1。 複数のヘッダーフィールド対ただ一つのヘッダーフィールド
Use of a single header field for transporting command meta-syntax was rejected for a number of reasons.
ただ一つのヘッダーフィールドのコマンドメタ構文を輸送する使用は様々な意味で拒絶されました。
Such a field would require the creation of a new meta-syntax in order to describe the list commands (as opposed to the use of the widely deployed URL syntax which was chosen for this implementation). Every additional layer of complexity and newness reduces the likelihood of actual implementation because it will require additional work to support. Also, by using the existing URL syntax, we can profit from the end users' knowledge of that syntax and ability to use it even if their client applications do not support the list header fields.
そのような分野は、リストコマンド(この実装に選ばれた広く配布しているURL構文の使用と対照的に)について説明するために新しいメタ構文の作成を必要とするでしょう。 追加仕事を必要とするので、あらゆる追加層の複雑さと新しさは実際の実装の見込みをサポートに減少させます。 また、既存のURL構文を使用することによって、彼らのクライアントアプリケーションがリストヘッダーフィールドをサポートしないでも、私たちはその構文とそれを使用する能力に関するエンドユーザの知識から利益を得ることができます。
Restricting the transport of meta-syntax to the use of a single header field also introduces complications with header field size limitations. Most individual commands can easily be described in a single line, but describing a multitude of commands can take up many lines in the field and runs a greater risk of being modified by an existing server on route.
また、メタ構文の輸送をただ一つのヘッダーフィールドの使用に制限すると、複雑さはヘッダーフィールドサイズ制限で導入されます。 単線で容易にほとんどの個々のコマンドについて説明できますが、コマンドの多数について説明すると、その分野で多くの系列を始めることができて、既存のサーバによって変更されるより高い危険はルートに冒されます。
The client implementation is also easier with multiple fields, since each command can be supported and implemented individually, completely independent of the others. Thus, some list managers or mail clients can choose to implement a subset of the fields based on the specific needs of their individual lists.
また、複数の分野ではクライアント実装も、より簡単です、個別に各コマンドをサポートして、実装することができるので、完全に他のものの如何にかかわらず。 したがって、何人かのリストマネージャかメールクライアントが、それらの個々のリストの特定の必要性に基づく分野の部分集合を実装するのを選ぶことができます。
Finally, the format described in this document is simple and well recognized, which reduces the chances of errors in implementation and parsing.
最終的に、本書では説明された形式は、簡単でよく認識されています(実装と構文解析における、誤りの可能性を小さくします)。
A.2. URLs vs. parameter lists
A.2。 URL対パラメータ・リスト
URLs are already an established syntax which is flexible, well- defined, and in wide spread use. As its definition matures and expands, the abilities of the list fields will grow as well, without requiring modification of this proposal. URLs are well prepared to handle future protocols and developments, and can easily describe the different existing access protocols such as mailto, http and ftp.
URLは既によく定義される、および広い普及の使用でのフレキシブルな確立した構文です。 定義が熟して、広がるのに従って、また、リスト分野の能力は成長するでしょう、この提案の変更を必要としないで。 URLは、将来のプロトコルと開発を扱うようによく準備されて、容易にmailtoや、httpやftpなどの異なった既存のアクセス・プロトコルについて説明できます。
Neufeld & Baer Standards Track [Page 8] RFC 2369 URLs as Meta-Syntax July 1998
ニューフェルドとベヤーStandardsはメタ構文1998年7月としてRFC2369URLを追跡します[8ページ]。
Many clients already have functionality for recognizing, parsing, and evaluating URLs, either internally or by passing the request to a helper application. This makes implementation easier and more realistic. As an example, this existing support for URL parsing allowed us to add prototype list header functionality to existing mail clients (Eudora and Emailer for the Macintosh) without modifying their source code.
多くのクライアントには、機能性が、既にURLを認識して、分析して、評価するか、内部的または要求に支援アプリケーションに合格することによって、あります。 これで、実装は、より簡単でより現実的になります。 例として、URL構文解析のこの既存のサポートで、彼らのソースコードを変更しないで、私たちは既存のメールクライアント(マッキントッシュのためのユードラとEmailer)にプロトタイプリストヘッダーの機能性を加えることができました。
A.3. Why not just create a standard command language?
A.3。 なぜただ標準のコマンド言語を作成しませんか?
A standard command language, supported by all email list services, would go a long way to reducing the problems of list access that currently plague existing services. It would reduce the amount of learning required by end users and allow for a number of common support tools to be developed.
すべてのメールリストサービスでサポートされた標準のコマンド言語は既存のサービスを苦しめにそんなに現在リストアクセスの問題を減少させるのにはるばる行くでしょう。 それは、エンドユーザによって必要とされた学習の量を減少させて、多くの一般的なサポートツールが開発されるのを許容するでしょう。
However, such standardization does pose problems in the areas of multi-lingual support and the custom needs of individual mailing lists. The development of such a standard is also expected to be met with a slow adoption rate by software developers and list service providers.
しかしながら、そのような標準化は多言語サポートの領域と個々のメーリングリストのカスタム必要性で問題を引き起こします。 また、そのような規格の開発はソフトウェア開発者とリストサービスプロバイダーによって遅い採用率に会われると予想されます。
These points do not preclude the development of such a standard (in fact, it would suggest that we should start sooner rather than later), but we do need a solution that can be widely supported by the current list services.
これらのポイントはそのような規格の開発を排除しませんが(事実上、それは、私たちが後でというよりむしろより早く始めるべきであると示唆するでしょう)、私たちは現在のリストサービスで広くサポートすることができるソリューションを必要とします。
We can support most existing list manager command syntaxes without a standard command language. By using URLs, we allow alternate access methods a standard command language probably wouldn't enable, such as web based control.
私たちは、標準のコマンド言語なしで大部分が既存のリストマネージャコマンド構文であるとサポートすることができます。 URLを使用することによって、私たちは標準のコマンド言語がたぶんウェブに基づいているコントロールなどのように可能にしない代替のアクセス法を許します。
Finally, client support for a standard command language is not at all clear or necessarily simple to implement. The variety and large number of commands existing today would require complicated user interfaces which could be confusing and difficult to implement. By restricting this proposal to the core functions, the client
最終的に、標準のコマンド言語のクライアントサポートは、全くないか、または実装するのが必ず簡単であるというわけではありません。 バラエティーと今日存在する多くのコマンドが、紛らわしくて、実装するのが難しいかもしれない複雑なユーザインタフェースを必要とするでしょう。 この提案をコア機能に制限するクライアントで
implementation is much simpler, which significantly increases the likelihood of implementation (as evidenced by the support already announced by a number of client and server application authors).
実装ははるかに簡単です(実装の可能性をかなり広げます)(多くのクライアントとサーバ・アプリケーション作者によって既に発表されたサポートで証明されるように)。
A.4. Internationalization
A.4。 国際化
Multilingual support is up to the URL standard. If URLs support it, then the List- header fields support it. This is another advantage of using URLs as the building blocks for the list header fields.
多言語サポートはURL規格まで達しています。 URLがそれをサポートするなら、Listヘッダーフィールドはそれをサポートします。 これはリストヘッダーフィールドにブロックとしてURLを使用する別の利点です。
Neufeld & Baer Standards Track [Page 9] RFC 2369 URLs as Meta-Syntax July 1998
ニューフェルドとベヤーStandardsはメタ構文1998年7月としてRFC2369URLを追跡します[9ページ]。
A.5. Variable Substitution
A.5。 可変代替
Variables would allow the List- header fields to accommodate nearly every existing list manager. However, it would immeasurably increase the complexity of the entire proposal, and possibly involve redefining the URL standard, or force us to use something more complicated (and hence more difficult to implement) than URLs to describe the command syntax.
変数で、Listヘッダーフィールドはほとんどすべての既存のリストマネージャを収容できるでしょう。 しかしながら、それによって、私たちは、測り知れないときに全体の提案の複雑さを増強して、ことによるとURL規格を再定義することを伴うか、またはコマンド構文について説明するのにやむを得ずより複雑で何か(したがって、URLより実装する難しい)であるものを使用するでしょう。
Parameters would either have to be mandatory (i.e. the user agent doesn't submit the message if it doesn't know what text to substitute) or you need a way to say "if you know this parameter, add its text here; otherwise, do this" where "this" is either: (a) substitute a constant string, or (b) fail.
パラメタが義務的でなければならないでしょうか(どんなテキストを代入したらよいかを知らないなら、すなわち、ユーザエージェントはメッセージを提出しません)、またはあなたは「このパラメタを知っているなら、ここでテキストを加えてください」と言う方法を必要とします。 「これ」がどちらかであるところの「さもなければ、これをしてください」: (a) (b) 一定のストリングを置換するか、または失敗してください。
The reason you would want a facility like this is because some list server applications insist on having certain parameters like users' names, which the user agent might or might not know. e.g. listserv insists on having a first name and a last name if you supply either one.
あなたがこのような施設が欲しいだろう理由はいくつかのリストサーバ・アプリケーションが、ユーザエージェントが知っているか、または知らないかもしれないユーザの名前のようなあるパラメタを持っていると主張するからです。例えば、listservは、あなたがどちらかを供給するなら名と姓を持っていると主張します。
Which could lead to something like the UNIX shell syntax, where
${foo-bar} means substitute the value of parameter "foo" if "foo" is
defined, else substitute the string "bar". Perhaps $foo would mean
"substitute the value of parameter foo if it is defined, else
substitute the empty string"
何かUNIXシェル構文のようなものに通じることができました。(そこでは、$foo-バーが、"foo"が定義されるなら"foo"というパラメタの値を代入することを意味して、代用品はほかのストリング「バー」です)。 恐らく$fooは、「それが空が結ぶ定義されてほかの代用品であるならパラメタfooの値を代入します。」と意味するでしょう。
This all seems far too complicated for the gains involved, especially since the use of variables can often be avoided.
これはすべて、特に変数の使用をしばしば避けることができるのでかかわる利得のためにはるかに複雑に見え過ぎます。
The use of variables in the command syntaxes of list services appears to be lessening and does not, in any case, apply to all commands. While the unsubscribe and subscribe command header fields may not be usable by those systems which require the use of variables, the help field will still provide end users with a consistent point of access through which they can get support for their use of the list.
リストサービスのコマンド構文における変数の使用は、少なくなっているように見えて、どのような場合でも、すべてのコマンドに適用されません。 外してください。そうすれば、ヘッダーがさばく申し込みコマンドは変数の使用を必要とするそれらのシステムで使用可能である必要はありません、とそれでも、助け分野が彼らが彼らのリストの使用のサポートを得ることができるアクセスのa一貫したポイントにエンドユーザを前提とするでしょう。
A.6. Why not use a specialized MIME part instead of header fields?
A.6。 なぜヘッダーフィールドの代わりに専門化しているMIME部分を使用しませんか?
MIME parts were considered, but because most mail clients currently either don't support MIME or are not equipped to handle such specialized parts - such an implementation would result in problems for end users. It is also not as easy for many list servers to implement MIME as it is to implement new header fields.
MIMEの部品をほとんどのメールクライアントが現在MIMEをサポートしないので考えられたか、またはそのような専門化している部分を扱うために備えていません--そのような実装はエンドユーザのための問題をもたらすでしょう。 また、それは多くのリストサーバが新しいヘッダーフィールドを実装することになっているのとMIMEを同じくらい実装しにくいです。
However, we are looking at the design of a MIME part to more fully describe list command syntax, as well as trying to find ways to get it supported by the applicable software.
しかしながら、私たちは、適切なソフトウェアでそれをサポートさせる方法を見つけようとすることと同様にリストコマンド構文について、より完全に説明するためにMIME部分のデザインを見ています。
Neufeld & Baer Standards Track [Page 10] RFC 2369 URLs as Meta-Syntax July 1998
ニューフェルドとベヤーStandardsはメタ構文1998年7月としてRFC2369URLを追跡します[10ページ]。
A.7. Why include a Subscribe command?
A.7。 なぜインクルード。登録は命令しますか?
Subscribe and Unsubscribe are the key commands needed by almost every list. Other commands, such as digest mode, are not as widely supported.
登録と登録削除、ほとんどあらゆるリストによって必要とされた主要なコマンドはそうですか? ダイジェストモードなどの他のコマンドは同じくらい広くサポートされません。
Additionally, users who have unsubscribed (before going on vacation, or for whatever other reason) may want to resubscribe to a list. Or, a message may be forwarded/bounced from a subscriber to a non- subscriber. Or, the user may change addresses and want to subscribe from their new address. Having the List-Subscribe field available could certainly help in all these cases.
さらに、外した(休暇を取るか、またはいかなる他の理由でも前に)ユーザはリストへのresubscribeに欲しいかもしれません。 または、メッセージを加入者から非加入者まで転送するか、または弾ませるかもしれません。 または、ユーザは、アドレスを変えて、それらの新しいアドレスから申し込みたがっているかもしれません。 確かに、利用可能なList申し込んでいる分野を持っているのはこれらのすべての場合で助けることができました。
A.8. The Dangers of Header Bloat
A.8。 ヘッダーの危険はふくれます。
At what point are there just too many header fields? It really varies on a list by list basis. On some lists, the majority of users will never be aware of a field unless the client software provides some alternative user interface to it (akin to the Reply-To field). On others, the users will often see the header fields of messages and would be able to recognize the function of the URLs contained within.
どんなポイントで、ちょうどあまりに多くのヘッダーフィールドがありますか? それは本当にリストでリスト基礎で異なります。 クライアントソフトウェアがいくらかの代替のユーザーインタフェースをそれに提供しないといくつかのリストでは、ユーザの大部分が分野を決して意識しない、(同系、Reply、-、分野) 他のものに、ユーザは、しばしばメッセージのヘッダーフィールドを見て、URLの機能を中に含まれた状態で認識できるでしょう。
The flexibility afforded by the protocol described in this document (in that the header fields may be individually implemented as deemed appropriate) provides list administrators with sufficient 'room to maneuver' to meet their individual needs.
本書では(適切であると考えられるようにヘッダーフィールドが個別に実装されるかもしれないので)説明されたプロトコルによって提供された柔軟性は彼らの個々の需要を満たすことができるくらいの'操縦する余地'をリスト管理者に提供します。
Neufeld & Baer Standards Track [Page 11] RFC 2369 URLs as Meta-Syntax July 1998
ニューフェルドとベヤーStandardsはメタ構文1998年7月としてRFC2369URLを追跡します[11ページ]。
B. Client Implementation
B。 クライアント実装
B.1. Guidelines
B.1。 ガイドライン
For 'mailto' URL based commands, mail client applications may choose to provide specialized feedback (such as presenting a dialog or alert), instead of the actual command email message, asking for command confirmation from the user. The feedback should identify the message destination and command within a more descriptive explanation. For example:
'mailto'に関しては、URLはコマンドを基礎づけて、メールクライアントアプリケーションは、専門化しているフィードバック(対話か警戒を提示などなどの)を提供するのを選ぶかもしれません、実際のコマンドメールメッセージの代わりに、ユーザからコマンド確認を求めて。 フィードバックは、より描写的である説明の中でメッセージの目的地とコマンドを特定するべきです。 例えば:
"Do you want to send the unsubscription command 'unsubscribe
somelist' to 'somelist-request@some.host.com'? Sending the command
will result in your removal from the associated list."
「あなたは' somelist-request@some.host.com 'への'somelistを外してください'を非購読コマンドに送りたいですか?」 「コマンドを送ると、関連リストからのあなたの取り外しはもたらされるでしょう。」
If the user has multiple email addresses supported by the mail client, the client application should prompt the user for which address to use when subscribing or performing some other action where the address to use cannot be specifically determined. When unsubscribing or such, the address that is subscribed should be used, unless that is not known by the application and cannot be determined from the message headers.
ユーザがメールクライアントに複数のEメールアドレスをサポートさせるなら、クライアントアプリケーションは、ある他の動作を申し込むか、または実行するとき、使用するアドレスが明確に決定できないところでどのアドレスを使用したらよいかためにユーザをうながすべきです。 外すかそのようなものであるときに、申し込まれるアドレスは使用されるべきです、それがアプリケーションで知られていなくて、メッセージヘッダーから決定できるなら。
B.2. Implementation Options
B.2。 実装オプション
The following implementation possibilities are suggested here to give some idea as to why these new header fields will be useful, and how they could be supported.
以下の実装の可能性は、これらの新しいヘッダーフィールドがなぜ役に立つか、そして、どうしたらそれらはサポートすることができたかに関して何らかの考えを与えるためにここに示されます。
In most cases, it may be helpful to disable the interface for the commands when not applicable to the currently selected message.
現在選択されたメッセージに適切でないときに、多くの場合、コマンドのためにインタフェースを無効にするのは役立っているかもしれません。
B.2.1. Key combinations and command lines
B.2.1。 主要な組み合わせとコマンドライン
On text based systems which utilize command lines or key combinations, each field could be implemented as a separate command. Thus one combination would subscribe the user, another would unsubscribe, a third request help, etc. The commands would only be available on messages containing the list header fields.
テキストでは、別々のコマンドとしてコマンドラインか主要な組み合わせ、各分野を利用するベースのシステムは導入されることができました。 したがって、1つの組み合わせがユーザを申し込んで、別のものは、外して、3分の1に助けを要求するでしょうなど。 リストヘッダーフィールドを含んでいて、コマンドは単にメッセージで利用可能でしょう。
B.2.2. Menu items
B.2.2。 メニュー項目
On graphical systems which have menus, these commands could take the form of a menu or sub-menu of items. For example, a "Lists" menu might appear when viewing messages containing the header fields, with items named "Subscribe", "Unsubscribe", "Get Help", "Post Message to
メニューを持っているグラフィカルなシステムの上では、これらのコマンドは項目に関するメニューかサブメニューの形を取るかもしれません。ヘッダーフィールドを含むメッセージを見るとき、例えば、「リスト」メニューは現れるかもしれません、項目が「申し込んでください」と命名されている状態で、と「外してください」、「ヘルプを得てください」は「メッセージを掲示します」。
Neufeld & Baer Standards Track [Page 12] RFC 2369 URLs as Meta-Syntax July 1998
ニューフェルドとベヤーStandardsはメタ構文1998年7月としてRFC2369URLを追跡します[12ページ]。
List", "Contact List Owner" and "Access List Archive". This menu could be disabled when not applicable to the current message or disappear entirely.
「記載してください」と「リスト所有者に連絡してください」と「リストアーカイブにアクセスしてください。」 このメニューは、現在のメッセージに適切でないときに、障害があるか、または完全に見えなくなることができました。
B.2.3. Push Buttons and Pallettes
B.2.3。 押しボタンと脇下当て
On graphical window systems, buttons could be placed in the window of the message, a toolbar, or in a floating pallette of their own. Each button could correspond to a command, with names "Subscribe", "Unsubscribe", "Get Help", "Post to List", "List Owner" and "Archive". These buttons or pallettes could be disabled when not applicable to the current message or disappear entirely.
グラフィカルなウィンドウシステムでは、メッセージ、ツールバーの窓かそれら自身の浮いている脇下当てにボタンを置くことができました。 各ボタンは名前「申し込んでください」、「外してください」、「ヘルプを得てください」、「記載するポスト」、「リスト所有者」、および「アーカイブ」でコマンドに対応できました。 これらのボタンか脇下当てが、現在のメッセージに適切でないときに、障害があるか、または完全に見えなくなることができました。
B.2.4 Feedback to the User
ユーザへのB.2.4フィードバック
If using a dialog interface (or other feedback element) the client application MUST include an option for the user to review (and possibly modify) the message before it is sent. The application may also find it useful to provide a link to more detailed context- sensitive assistance about mail list access in general.
そして、対話インタフェース(他のフィードバック要素)を使用するならユーザが論評するようにクライアントアプリケーションがオプションを含まなければならない、(ことによると変更する、)、それの前のメッセージを送ります。 また、アプリケーションは、一般に、メール・リストアクセスに関して、より詳細な文脈敏感な支援へのリンクを提供するのが役に立つのがわかるかもしれません。
References
参照
[RFC822] Crocker, D., "Standard for the Format of ARPA
Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill,
"Uniform Resource Locators (URL)" RFC 1738, December 1994.
[RFC1738] バーナーズ・リーとT.とMasinter、L.とM.McCahill、「Uniform Resource Locator(URL)」RFC1738、1994年12月。
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
Functions", RFC 2142, May 1997.
[RFC2142]クロッカー(D.、「共益サービス、役割、および機能のためのメールボックス名」、RFC2142)は1997がそうするかもしれません。
[RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL
scheme", RFC 2368, July 1998.
1998年7月の[RFC2368]ホフマンとP.とMasinter、L.とJ.Zawinski、「mailto URL体系」RFC2368。
[5] "List-Header" Mail list. list-header@list.nisto.com
<URL:http://www.nisto.com/listspec/mail/>
<URL:http://www.nisto.com/listspec/>
[5] 「リストヘッダー」メールリスト list-header@list.nisto.com 、lt;、URL: http://www.nisto.com/listspec/mail/ ><URL: http://www.nisto.com/listspec/ >。
[6] "ListMom-Talk" Mail list. listmom-talk@skyweyr.com
<URL:http://cgi.skyweyr.com/ListMom.Home>
[6] 「ListMom-話」メールリスト listmom-talk@skyweyr.com 、lt;、URL: http://cgi.skyweyr.com/ListMom.Home >。
Neufeld & Baer Standards Track [Page 13] RFC 2369 URLs as Meta-Syntax July 1998
ニューフェルドとベヤーStandardsはメタ構文1998年7月としてRFC2369URLを追跡します[13ページ]。
Editors' Addresses
エディタのアドレス
Joshua D. Baer Box 273 4902 Forbes Avenue Pittsburgh, PA 15213-3799 USA
ジャシュアD.ベヤー箱273の4902フォーブズAvenueピッツバーグ、PA15213-3799米国
EMail: josh@skyweyr.com
メール: josh@skyweyr.com
Grant Neufeld Calgary, Alberta Canada
ニューフェルド・アルバータカルガリー(カナダ)を与えてください。
EMail: grant@acm.org Web: http://www.nisto.com/
メール: grant@acm.org ウェブ: http://www.nisto.com/
Neufeld & Baer Standards Track [Page 14] RFC 2369 URLs as Meta-Syntax July 1998
ニューフェルドとベヤーStandardsはメタ構文1998年7月としてRFC2369URLを追跡します[14ページ]。
Full Copyright Statement
完全な著作権宣言文
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Neufeld & Baer Standards Track [Page 15]
ニューフェルドとベヤー標準化過程[15ページ]
一覧
スポンサーリンク
