RFC5241 日本語訳
5241 Naming Rights in IETF Protocols. A. Falk, S. Bradner. April 1 2008. (Format: TXT=25304 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Falk
Request for Comments: 5241 BBN
Category: Informational S. Bradner
Harvard University
1 April 2008
コメントを求めるワーキンググループA.フォーク要求をネットワークでつないでください: 5241年のBBNカテゴリ: 情報のS.ブラドナーハーバード大学2008年4月1日
Naming Rights in IETF Protocols
IETFの権利をプロトコルと命名します。
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document proposes a new revenue source for the IETF to support standardization activities: protocol field naming rights, i.e., the association of commercial brands with protocol fields. This memo describes a process for assignment of rights and explores some of the issues associated with the process. Individuals or organizations that wish to purchase naming rights for one or more protocol fields are expected to follow this process.
IETFが標準化活動を支持するように、このドキュメントは新しい財源を提案します: プロトコル分野で分野名称の権利、すなわち、商業ブランドの協会について議定書の中で述べてください。 このメモは、権利の課題のための過程について説明して、過程に関連している問題のいくつかを探ります。 個人か1つ以上のプロトコル分野への名称の権利を購入したがっている組織がこの過程に従うと予想されます。
1. Introduction
1. 序論
Normal engineering practice involves assigning names to fields in network protocols. These names are generally carefully chosen to reflect the function of the field, for example, the IPv4 Destination Address field.
正常なエンジニアリング方式は、名前を分野に割り当てることをネットワーク・プロトコルに伴います。 一般に、これらの名前は、例えばIPv4 Destination Addressがさばく分野の関数を反映するために慎重に選ばれています。
As protocol designers engage in their work, many become intensely involved with these protocol fields. Some of the most intense discussions within the IETF have been over details about such fields. In fact, it is an advantage to the continued viability of the IETF that dueling is outlawed in the countries in which it meets.
プロトコルデザイナーが彼らの仕事に従事しているとき、多くがこれらのプロトコル分野に非常にかかわるようになります。 そのような分野に関する詳細の上にIETFの中の最も激しい議論のいくつかがありました。 事実上、それは決闘して、それが会う国で禁止されるIETFの継続的な生存力の利点です。
But the financial realities of funding the Internet engineering and standardization processes may dictate that the IETF must consider whether names associated with such protocol fields represent an asset capable of responsible monetization. This notion may be offensive to some protocol purists; however, we believe the exigencies of the situation make the proposal below worthy of consideration.
しかし、インターネット工学と標準化過程に資金を供給する財政的な現実は、IETFが、そのようなプロトコル分野に関連している名前が原因となる貨幣化ができる資産を表すかどうか考えなければならないと決めるかもしれません。 何人かのプロトコル純粋主義者にとって、この概念は無礼であるかもしれません。 しかしながら、私たちは、状況の緊急事態が考慮にふさわしい下で提案をすると信じています。
Falk & Bradner Informational [Page 1] RFC 5241 Naming Rights 1 April 2008
権利を2008年4月1日と命名するフォークとブラドナーの情報[1ページ]のRFC5241
This document describes a process and some issues associated with managing the sale of commercial branding rights (or naming rights) for IETF protocol fields. The authors believe that this modest proposal may serve as a source of revenue capable of supporting IETF standardization activities for years to come.
このドキュメントは商業商標を付けることの販売が正す管理に関連している過程といくつかの問題(権利を命名して)についてIETFプロトコル分野に説明します。 作者は、この穏やかな提案が長年IETF標準化活動を支持できる財源として機能するかもしれないと信じています。
This proposal arose from the realization that the sports industry has made energetic and successful use of naming rights, for stadiums in particular, e.g., the Staples Center in Los Angeles (basketball), Qualcomm Stadium in San Diego (football), Minute Maid Park in Houston (baseball), and the Aaron's "Lucky Dog" get-a-lap-back (car racing).
この提案はスポーツ産業がロサンゼルス(バスケットボール)、サンディエゴのクァルコムスタジアム(フットボール)、ヒューストンのミニッツメイドPark(野球)、およびアーロンの膝を到着して戻させている「果報者」で特に、そして、例えば、ステープルズセンターとスタジアムへの権利を命名することのエネルギッシュでうまくいっている使用を(車のレース)にしたという認識から起こりました。
The Internet has enabled a new online economy that, even in the wake of the burst bubble in early 2000, is generating astounding growth and new services. It is clear that many old-economy companies would place high value on being associated with the new online economy and would be willing to pay for the privilege. Internet protocols are used around the world in myriad operating systems and devices. To be part of the Internet protocols is to be part of the engine that is revolutionizing how commerce is done. Many protocol fields are displayed in popular user applications either as key aspects of the GUI or in error or diagnostic messages. By requiring the use of the branded protocol field, the IETF is in a position to put client company brands in front of not only the thousands of software developers who build with these protocols but also the hundreds of millions of users who benefit from them. Finally, those who license and brand a protocol field will be able to use that field in their other marketing and claim, truthfully, that they are "in the network".
インターネットは2000年前半の炸裂気泡の後でさえ驚くべき成長と新種業務を発生させている新しいオンライン経済を可能にしました。 多くのオールドエコノミー会社が、新しいオンライン経済に関連しているのに高い値を置いて、特権の代価を払っても構わないと思っているのは、明確です。 インターネットプロトコルは無数のオペレーティングシステムと装置で世界中で使用されます。 インターネットプロトコルの一部であることは商業がどう完了しているかを変革しているエンジンの一部であることです。 GUIの特徴か誤りか診断メッセージにおけるポピュラーなユーザアプリケーションに多くのプロトコル野原を表示します。 商標を付けられたプロトコル分野の使用を必要とすることによって、IETFがこれらのプロトコルで建てる何千人ものソフトウェア開発者だけではなく、彼らの利益を得る何億人ものユーザについて正面にクライアント会社のブランドを置く立場にあります。 最終的に、プロトコル分野を認可して、商標を付ける人は彼らの他のマーケティングとクレームで正直にその分野を使用できて、「ネットワーク」には彼らがいます。
This proposal includes creating a primary name value for each protocol field in the IANA registry and setting up a process whereby an organization or an individual can license the right to record a name of their choice in that field.
この提案は、IANA登録で第一の名前値をそれぞれのプロトコル分野に作成して、その分野で組織か個人が彼らの選択の名前を記録する権利を認可できる過程をセットアップするのを含んでいます。
This document makes the case for the need for additional revenue for the IETF (Section 2), followed by an introduction of the concept of branding in IETF protocols (Section 3). Several rules and constraints necessary to make such a revenue stream practical are then explored (Sections 4-14). Finally, this memo concludes with an initial assessment of the changes required by the IANA and RFC Editor to support such a service (Sections 15-17).
このドキュメントはIETFでプロトコルに(セクション3)と商標を付ける概念の導入があとに続いたIETF(セクション2)の追加収入の必要性のために弁護をします。 そして、そのような収入の流れを実用的にするのに必要ないくつかの規則と規制は探られます(セクション4-14)。 最終的に、このメモはIANAとRFC Editorがそのようなサービス(セクション15-17)を支持しなければならなかった変化の初期評価で締めくくります。
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Falk & Bradner Informational [Page 2] RFC 5241 Naming Rights 1 April 2008
権利を2008年4月1日と命名するフォークとブラドナーの情報[2ページ]のRFC5241
2. Revenue Needs
2. 収入の必要性
Running the IETF is not inexpensive. It was reported at the 71st IETF meeting in Philadelphia, PA, USA that the 2008 budget [BUDGET] for the IETF had surpassed US$4.5 M, up from $4.1 M in 2007. About US$3 M of revenue in this budget flows directly from IETF activities, including meeting fees and sponsorships, and the remainder flows from the Internet Society (ISOC). Over the last few years the IETF has had to raise meeting fees repeatedly in order to keep this budget balance reasonable.
IETFを走らせるのは安価ではありません。 フィラデルフィア(PA)(米国)における71番目のIETFミーティングでIETFのための2008年の予算[BUDGET]が4.5USドルのMを凌いだと報告されました、2007年の4.1ドルのMから。 この予算によるおよそ3USドルのMの収入は直接ミーティング料金と世話役を含むIETF活動から流れます、そして、残りはインターネット協会(ISOC)から流れます。 ここ数年間にわたって、IETFは、この予算バランスを妥当に保つために繰り返してミーティング料金を上げなければなりませんでした。
Raising an additional US$1 M from the rental of naming rights could significantly change the budget dynamics. Perhaps meeting fees could be reduced for all attendees or special subsidies could be provided to needy students, researchers, or job seekers. Other options for the use of the increased revenue could be sizing the break cookies large enough to feed a family of geeks for a week rather than the mere day and a half as was the case at the 71st IETF, or renting out a bar for the working group chairs social rather than having to put up with the rowdy locals. There are many other equally deserving ways that the IETF could spend the resources generated by this proposal. It should be noted that any such benefits may have to be delayed for a few years to pay for the startup costs noted below.
名称の権利のレンタルからの追加1USドルMを上げると、予算力学はかなり変化するかもしれません。 恐らく、すべての出席者のためにミーティング料金を下げることができましたか、または苦学生、研究者、または求職者に特別な補助金を提供できました。 増収の使用のための別の選択肢はほんの日よりむしろ1週間半の間、乱暴なローカルを我慢しなければならないよりむしろ第71IETFのケースであった、またはワーキンググループいすのために社会的にバーを賃貸しているとしておたくの家族に食べさせることができるくらい大きい中断クッキーを大きさで分けているかもしれません。 他の多くの等しく値している道があります。IETFはこの提案で発生するリソースを費やすことができました。 どんなそのような利益も以下に述べられた始動コストの代価を払うために数年間遅れなければならないかもしれないことに注意されるべきです。
3. How Are Branded Protocol Fields Used?
3. 商標を付けられたプロトコル分野はどのように使用されますか?
3.1. Within the IETF
3.1. IETFの中で
When a protocol field name is licensed from the IETF, all future IETF activities, and documentation for products claiming to conform to IETF standards, MUST use the complete branded name. The output from protocol implementations, and associated documentation, MUST be considered non-conformant if the complete branded name is not used.
プロトコルフィールド名がいつ、IETF、すべての今後のIETF活動から認可されるか、そして、IETF規格に従うと主張する製品のためのドキュメンテーションは完全な商標を付けられた名前を使用しなければなりません。 完全な商標を付けられた名前が使用されていないなら、非conformantであるとプロトコル実現、および関連ドキュメンテーションからの出力を考えなければなりません。
3.2. Externally
3.2. 外部的に
The official IETF name for a purchased field is the complete branded name. Thus, all externally generated documentation that references the protocol must be considered incomplete unless it used the complete branded name where one exists. The IETF leaves it to the licensee to enforce the use of complete branded names in non-IETF documents.
購入された分野への公式のIETF名は完全な商標を付けられた名前です。 したがって、1つが存在する完全な商標を付けられた名前を使用しなかったなら、不完全であるとプロトコルに参照をつけるすべての外部的に発生したドキュメンテーションを考えなければなりません。 IETFは、非IETFドキュメントにおける完全な商標を付けられた名前の使用を実施するように免許所有者に任せます。
Falk & Bradner Informational [Page 3] RFC 5241 Naming Rights 1 April 2008
権利を2008年4月1日と命名するフォークとブラドナーの情報[3ページ]のRFC5241
4. Names Must Be in Good Taste
4. ハイセンスには名前があるに違いありません。
The combination of brand names and protocol field names must avoid uses that may be considered offensive by some part of the Internet community. Name purchases shall be reviewed for taste. Prospective purchasers must prepare a proposal for how the branded protocol name will be used in advertising or other media. (Note that a well- developed taste-review process may prove useful for other IETF activities, for example, IETF working group names, T-shirts, and host presentations.)
ブランド名とプロトコルフィールド名の組み合わせはインターネットコミュニティの何らかの部分によって不快であると考えられるかもしれない用途を避けなければなりません。 名前購買は好みのために見直されるものとします。 見込み客は、商標を付けられたプロトコル名が広告か他のメディアにどう使用されるかために提案を準備しなければなりません。 (よく開発された味吟味の過程が例えば、他のIETF活動、IETFワーキンググループ名、Tシャツ、およびホストプレゼンテーションのために有用であることが分かるかもしれないことに注意してください。)
Within the limits of taste, the branded protocol field may be used for any purpose.
味の限界の中では、商標を付けられたプロトコル分野はどんな目的にも使用されるかもしれません。
5. When Names Change
5. 名前が変化する場合
As has been discovered in other areas where naming rights are sold or leased, commercial realities and developments mean that a brand name can suddenly go out of favor or even cease to denote an existing entity. In addition, branding is leased (i.e., sold to be used over a limited time) and the branding for a particular field may change when the lease is up. Thus, there must be a mechanism to change branding when needed. See the IANA Considerations, RFC Editor Considerations, and Tools Considerations sections for more information.
名称の権利を販売するか、または賃貸する他の領域で発見されたように、商業現実と開発は、ブランド名が好意から突然行くことができることを意味するか、または既存の実体を指示するのをやめさえします。 さらに、商標を付けることは賃貸されます、そして、(すなわち、限られた時間使用されるために、販売します)特定の分野のための商標を付けるのはリースがいつ上がっているかを変えるかもしれません。 したがって、必要であると、商標を付けることを変えるメカニズムがあるに違いありません。 詳しい情報に関してIANA Considerations、RFC Editor Considerations、およびTools Considerations部を見てください。
6. Example Names
6. 例の名
The most effective names are those that pair the semantics of a field with a characteristic desirable to a sponsor. The following examples of good and bad pairings illustrate how an appropriate pairing can be appealing.
最も効果的な名前はスポンサーにとって、望ましい特性と分野の意味論を対にするものです。 善悪の組み合わせに関する以下の例は適切な組み合わせがどう魅力的である場合があるかを例証します。
6.1. Acceptable Taste-Wise
6.1. 許容できる、的である味がしてください。
IP: Garmin GPS Destination Address
IP: White & Day Mortuary Time-to-live
TCP: Princess Cruise Lines Port Number
ARP: Springfield Preschool Timeout
BGP: Sharpie Marker field
TFRC: Traveler's Insurance Loss Period
SCTP: Hershey's Chunk {type|flags|length}
SMTP: eHarmony HELO
IP: Garmin GPS目的地アドレスIP: ホワイトと日死体置場生きる時間TCP: Cruise Lines姫は数のARPを移植します: スプリングフィールドの保育園のタイムアウトBGP: 詐欺師MarkerはTFRCをさばきます: 旅行者の保険損失の期間のSCTP: ハーシーの塊のタイプ|旗|長さのSMTP: eHarmony HELO
Falk & Bradner Informational [Page 4] RFC 5241 Naming Rights 1 April 2008
権利を2008年4月1日と命名するフォークとブラドナーの情報[4ページ]のRFC5241
Protocol names appear within the fields of other protocols; therefore, the protocols themselves may be candidates for branding:
プロトコル名は他のプロトコルの分野の中に現れます。 したがって、プロトコル自体は以下に商標を付ける候補であるかもしれません。
BEEP: AAA BEEP
SOAP: Downey SOAP
PPP: FloMax PPP
ビープ音: トリプルAは石鹸を鳴らします: ダウニー石鹸ppp: FloMax ppp
There is no requirement for branding to be limited to company names or other trademarked terms. For example, a publisher could decide to honor one of their authors:
会社名か他の商標登録された用語まで制限されるために、商標を付ける要件は全くありません。例えば、出版社は、彼らの作者のひとりを光栄に思うと決めることができました:
The Thomas Wolfe Source Address Field
トーマスウルフソースアドレス・フィールド
6.2. In Bad Taste
6.2. 悪趣味で
SIP: Seagrams Vodka SIP Event
SIP: Calvin Klein Event Package
IP: Viagra Total Length
一口: Seagramsウオッカ一口イベント一口: カルヴァンクラインイベントパッケージIP: バイアグラ、全長
6.3. Confusing Names
6.3. 名前を混乱させます。
Places where the brand could interfere with the understanding of the protocol are prohibited:
ブランドがプロトコルの理解を妨げることができた場所は禁止されています:
SMTP: US Postal Service Mail command
IPv6: ITU-T Protocol field
IKE: RSA Vendor ID
SMTP: 米国Postal ServiceメールコマンドIPv6: ITU-Tプロトコル分野IKE: RSA業者ID
6.4. Valid Names
6.4. 妥当な名前
In order to be printed in the ASCII-only Real-RFC (described in Section 16) all brands must include an ASCII form. The ASCII name MUST conform to the requirements in RFC 2223 [RFC2233]. The brand MAY optionally include a UTF-8 version for use in non-ASCII representations. See RFC 3629 [RFC3629].
ASCIIだけレアル-RFC(セクション16では、説明される)に印刷されるために、すべてのブランドがASCIIフォームを含まなければなりません。 ASCII名はRFC2223[RFC2233]の要件に従わなければなりません。 ブランドは任意に非ASCII表現における使用のためのUTF-8バージョンを含むかもしれません。 RFC3629[RFC3629]を見てください。
7. Who Can Buy Naming Rights?
7. だれが名称の権利を買うことができますか?
Any organization or individual can purchase the right to brand a protocol field. The IETF will not undertake to ensure that the purchasing organization has the right to use the name they choose to use. All purchasing organizations MUST indemnify the IETF against any challenges to the authority of the purchasing organization to use the name.
どんな組織や個人もプロトコル分野に商標を付ける権利を購入できます。 IETFは、彼らが使用するのを選ぶ名前を使用するために購入組織が権利があるのを保証するのを引き受けないでしょう。 すべての購入組織が購入組織が名前を使用する権威へのどんな挑戦に対してIETFを保障しなければなりません。
Falk & Bradner Informational [Page 5] RFC 5241 Naming Rights 1 April 2008
権利を2008年4月1日と命名するフォークとブラドナーの情報[5ページ]のRFC5241
8. Scope of Naming Applicability
8. 命名の適用性の範囲
Because the application of IETF protocols is not controlled in a way that corresponds to legal jurisdictions, it is difficult to restrict naming rights to include just those places where a particular trademark may be registered. The process described in this memo does not include the use of geographic or geopolitical boundaries on the use of branded fields. The design team is working on a proposal to overcome this issue. If the design team is successful, the same proposal should find application in a number of areas of international diplomacy.
IETFプロトコルの応用が法的な管内に対応する方法で制御されないので、まさしく特定の商標が登録されるかもしれないそれらの場所を含む名称の権利を制限するのは難しいです。 このメモで説明された過程は商標を付けられた分野の使用の地理的であるか地政学の境界の使用を含んでいません。 デザインチームはこの問題に打ち勝つという提案に取り組んでいます。 デザインチームがうまくいくなら、同じ提案は国際的な外交の多くの領域で法則を見つけるべきです。
9. Who Can Sell Naming Rights?
9. だれが名称の権利を販売できますか?
The IETF SHALL retain the sole right to permit branded protocol names to be used within IETF protocols. The IETF MAY sell rights for external use of branded protocol names if the protocols have been developed within the IETF process and if the protocol field has not already been branded by someone else using the same process.
IETF SHALLは商標を付けられたプロトコル名がIETFプロトコルの中で使用されることを許可する独占権を保有します。 IETFの過程の中でプロトコルを開発してあって、プロトコル分野が他の誰かによって既に商標を付けられていないなら、IETF MAYは、同じ過程を使用することで商標を付けられたプロトコル名の外部の使用への権利を販売します。
10. Pricing
10. 価格設定
Multiple pricing strategies for the naming rights to protocol fields will likely be used over time. The primary objective of pricing is to enable the greatest possible revenue for the IETF. Initially, prices will be set by negotiation between the party wishing to purchase the naming right and the Internet Auction Board (IAB) representative. However, we strongly suggest migrating to an all pay auction (also known as a Tullock auction) for finding the optimal price when there are multiple bidders [KOVENOCK]. Alternatively, open-outcry auctions [EKLOR], perhaps with a secret reserve price, could be held at IETF meetings using a BoF session, permitting taste review and brand assignment (sale) to be conducted concurrently and with open participation. See [MILGROM] for information on various auction styles.
分野について議定書の中で述べる名称の権利のための複数の価格戦略が時間がたつにつれて、おそらく使用されるでしょう。 価格設定の主目的はIETFの可能な限り大きい収入を可能にすることです。 初めは、価格は名称の権利を購入したがっているパーティーとインターネットAuction Board(IAB)代表との交渉で設定されるでしょう。 しかしながら、私たちは、複数の入札者[KOVENOCK]がいるとき最適価格を見つけるためにすべての賃金オークションにわたることを(また、タロックオークションとして、知られています)強く提案します。 あるいはまた、恐らく秘密積立金価格で、IETFミーティングでBoFセッションを使用することで大声を出して行う売買注文オークション[EKLOR]を開かれることができるでしょう、味のレビューとブランド課題(販売)が同時にと開いている参加で行われることを許可して。 様々なオークションのスタイルの情報に関して[ミルグロム]を見てください。
11. Time of Ownership
11. 所有権の時間
The design team could not come to consensus on a default term of a lease of the authority to name a protocol field. It was split between a term that would best represent the half-life of an Internet startup (1 or 2 years) and a term that would best represent the half-life of a product offered by a mature Internet company (8 to 10 years). The idea of terms any longer than 10 years, for example, leases that would terminate when a protocol advanced on the standards track (i.e., roughly infinite), was discussed but generally discarded because so few companies survive in any recognizable form for that
デザインチームはプロトコル分野を命名する権威のリースに関するデフォルト諸条件のコンセンサスに来ることができませんでした。 それはインターネット始動(1年か2年)の半減期を最もよく表す用語と用語の間の熟しているインターネット会社(8〜10年)によって提供された製品の半減期を最もよく表す分裂でした。 もうとてもわずかな会社しか中で生き残らないので、議論しましたが、一般に、捨てられるのを除いて、認識可能ないずれもそれのために例えば、10年間のプロトコルが規格を進んだとき終わるリースが追跡されるより(すなわち、およそ無限の)形成されるという用語の考え
Falk & Bradner Informational [Page 6] RFC 5241 Naming Rights 1 April 2008
権利を2008年4月1日と命名するフォークとブラドナーの情報[6ページ]のRFC5241
length of time in the Internet space. In the end, the design team concluded that the lease term should be part of the negotiation between the IETF and the purchasing organization.
インターネット空間の時間の長さ。 結局、デザインチームは、リース用語がIETFと購入組織との交渉の一部であるべきであると結論を下しました。
12. How Are Naming Rights Purchased?
12. どのように名称の権利を購入しますか?
The right to name a protocol field is purchased using the following process: licensees complete an application where they identify the protocol field they wish to use and the particular RFC in which it appears (Internet-Draft tags are available for short term lease). At that time, they identify their brand and present their proposal for external use and length of ownership. The next step is a taste review followed by an auction or IAB negotiation. The purchase concludes with the IANA updating their protocol field name mapping database.
以下の過程を使用することでプロトコル分野を命名する権利を購入します: 免許所有者は彼らが使用したがっているプロトコル分野を特定するアプリケーションとそれが現れる特定のRFCを終了します(インターネット草稿タグは短期間リースに利用可能です)。 その時、彼らは、外部の使用と長さの所有権のためにそれらのブランドを特定して、自分達の提案を提示します。 次のステップは、オークションがあとに続いた味のレビューかIAB交渉です。 購買はそれらのプロトコルフィールド名マッピングデータベースをアップデートするIANAで締めくくります。
13. Dispute Resolutions
13. 論争の解決
All disputes arising from this process MUST be resolved using the ICANN Uniform Domain-Name Dispute-Resolution Policy [UDRP]. While the protocol fields are not domain names, branding them presents the same types of issues and we feel that it's better to make use of an existing process rather than to invent a new one.
ICANN Uniform Domain-名前Dispute-解決Policy[UDRP]を使用して、この過程から起こるすべての論争を解決しなければなりません。 プロトコル分野はドメイン名ではありませんが、それらに商標を付けるのは同じタイプの問題を提示します、そして、私たちは新しいものを発明するというよりむしろ既存の過程を利用しているほうがよいと感じます。
14. Future Expansions
14. 今後の拡大
If this proposal proves successful, it can be easily expanded to include other protocol features such as options and parameters. For example:
この提案が成功するなら、オプションやパラメタなどの他のプロトコル機能を含むように容易にそれを広げることができます。 例えば:
IPv6: The Herman Melville Jumbogram option
IPv6: ハーマン・メルヴィルのJumbogramオプション
15. IANA Considerations
15. IANA問題
Upon the adoption of this proposal the IANA SHALL set up a protocol field-to-brand-name database (the "IETF Protocol Branding Catalog") that includes all protocol fields in IETF-developed or -maintained protocols. This database can be bootstrapped from the existing protocol registries database [PROTREG], but this list will have to be augmented to include all fields in all IETF protocols, even the ones in which no IANA assignments are made.
この提案の採用のときに、IANA SHALLはプロトコル分野からブランド名へのIETFによって開発されたか維持されたプロトコルにすべてのプロトコル分野を含んでいるデータベース(「カタログに商標を付けるIETFプロトコル」)をセットアップします。 既存のプロトコル登録データベース[PROTREG]からこのデータベースを独力で進むことができますが、このリストは、すべてのIETFプロトコル(IANA課題が全くされないものさえ)にすべての分野を含むように増大しなければならないでしょう。
The two brand name fields associated with each protocol field (the ASCII field and the optional UTF-8 field) are initialized as NULL.
それぞれのプロトコル分野(ASCII分野と任意のUTF-8分野)に関連している2つのブランド名前欄がNULLとして初期化されます。
Falk & Bradner Informational [Page 7] RFC 5241 Naming Rights 1 April 2008
権利を2008年4月1日と命名するフォークとブラドナーの情報[7ページ]のRFC5241
Whenever the IETF leases a protocol field, the IANA SHALL enter the brand name(s) into the brand-named fields associated with the protocol field and SHALL set the lease termination date to the proper value.
IETFがプロトコル野原を賃貸するときはいつも、IANA SHALLはプロトコル分野に関連しているブランドで命名されたフィールドの中にブランド名を入力します、そして、SHALLはリース停止日時を固有値に設定します。
In addition, the IANA SHALL regularly scan the database to look for leases terminating within the next 30 days and inform the IETF of any such leases so that the IAB can approach the leaseholder to sign up for an additional term. The IANA SHALL remove any brand names from their database when the lease expires.
さらに、IANA SHALLは、IABが追加用語に申し込みをするために借家人に近づくことができるように、30日以内に終わるリースを探して、どんなそのようなリースについてもIETFに知らせるために定期的にデータベースをスキャンします。 リースが期限が切れると、IANA SHALLはそれらのデータベースからどんなブランド名も取り除きます。
16. RFC Editor Considerations
16. RFCエディタ問題
Upon the adoption of this proposal the RFC Editor SHALL create XML versions of all IETF RFCs. The XML must be such that a perfect copy of the original RFC can be produced using a tool such as xml2rfc [XML2RFC]. The XML versions of RFCs must identify all individual protocol fields using an XML protocol field element of the form:
この提案の採用のときに、RFC Editor SHALLはすべてのIETF RFCsのXMLバージョンを作成します。 XMLはxml2rfc[XML2RFC]などのツールを使用することでオリジナルのRFCの完全なコピーを生産できるようにものであるに違いありません。 RFCsのXMLバージョンは形式のXMLプロトコルフィールド要素を使用することですべての個々のプロトコル分野を特定しなければなりません:
<pfield name="IPv4 Destination Address"/>
<pfield名前=「IPv4送付先アドレス」/>。
(Doing this for all existing RFCs may involve some work.)
(すべての既存のRFCsのためにこれをすると、いくらかの仕事がかかわるかもしれません。)
As the XML RFCs are completed, the RFC Editor SHALL then create an ASCII version of the RFC from the XML file using the naming convention of "Real_RFCxxxx.txt". During the translation, each protocol field is looked up in the IANA protocol field-to-brand name database. If there is an ASCII brand name associated with the protocol field, the word "the" and the brand name are prepended to the IETF name for the field (unless the name appears in ASCII art where changing the length of the name would distort the art). For example, if the protocol field is "Destination Address" and the brand name in the IANA database is "Garmin GPS", the string "the Garmin GPS Destination Address" would be used in the Real_RFC. Changing the lengths of such names may require adjusting the other details of the document such as page numbering in the Table of Contents. The software to do some of the formatting might be a bit tricky.
そして、XML RFCsが完成するとき、RFC Editor SHALLは、XMLファイルから「本当の_RFCxxxx.txt」の命名規則を使用することでRFCのASCII版を作成します。 翻訳の間、それぞれのプロトコル分野はIANAプロトコル分野からブランド名へのデータベースで調べられます。 プロトコル分野に関連しているASCIIブランド名があれば、“the"という単語とブランド名は分野へのIETF名にprependedされます(名前が名前の長さを変えると芸術が歪められるASCII芸術に載っていない場合)。 例えば、プロトコル分野が「送付先アドレス」であり、IANAデータベースのブランド名が「Garmin GPS」であるなら、ストリング「Garmin GPS送付先アドレス」はレアル_RFCで使用されるでしょう。 そのような名前の長さを変えると、目次におけるページ付番などのドキュメントは他の詳細を調整するのが要求されるかもしれません。 形式のいくつかをするソフトウェアは少し精巧であるかもしれません。
The RFC Editor may optionally produce other non-normative versions of Real_RFCs. For example, a non-normative Portable Document Format (PDF) version may be created in addition to the ASCII Real_RFC version. The RFC Editor may use the UTF-8 brand, if present, in such alternate versions.
RFC Editorは任意にレアル_RFCsの他の非標準のバージョンを生産するかもしれません。 例えば、非標準のPortable Document Format(PDF)バージョンはASCIIレアル_RFCバージョンに加えて作成されるかもしれません。 そのような交互のバージョンに存在しているなら、RFC EditorはUTF-8ブランドを使用するかもしれません。
The Real_RFC SHALL be used for all normal purposes within the IETF and elsewhere with the original version being reserved as an archival reference.
レアル_RFC SHALL、すべての正常な目的には、IETF以内とほかの場所で記録保管所の参照として予約されるオリジナルバージョンで使用されてください。
Falk & Bradner Informational [Page 8] RFC 5241 Naming Rights 1 April 2008
権利を2008年4月1日と命名するフォークとブラドナーの情報[8ページ]のRFC5241
The RFC Editor SHALL rebuild all the Real_RFCs on a regular basis to create up-to-date Real_RFCs that reflect the current status of the protocol field licenses.
RFC Editor SHALLは、プロトコル分野ライセンスの現在の状態を反映する最新のレアル_RFCsを作成するために定期的にすべてのレアル_RFCsを再建します。
The RFC Editor SHALL provide a list of un-leased field names to the IANA for inclusion in the IETF Protocol Branding Catalog.
RFC Editor SHALLはIETFプロトコルBranding Catalogでの包含のために賃貸契約が結ばれていないフィールド名のリストをIANAに供給します。
17. Tool Builder Considerations
17. ツール建築業者問題
Upon the adoption of this proposal, the maintainer of the official xml2rfc tool SHALL update the tool to support the protocol field element and to consult the IANA database when being used to produce Real_RFCs (or Real_IDs). Upon the adoption of this proposal, document authors will be required to transmit the raw XML input file for the xml2rfc tool to the RFC Editor when the document is approved for publication.
この提案の採用のときに、レアル_RFCs(または、レアル_ID)を生産するのに使用されると、公式のxml2rfcツールSHALLの維持装置はプロトコルフィールド要素を支えて、IANAデータベースに相談するツールをアップデートします。 ドキュメントがこの提案の採用のときに公表のために承認されるとき、ドキュメント作者はxml2rfcツールのための生のXML入力ファイルをRFC Editorに伝えなければならないでしょう。
18. Security Considerations
18. セキュリティ問題
The fact that the IETF will not undertake to ensure that the purchasing organization has the right to use the name they choose to use can lead to mischief. For example, a Microsoft competitor could purchase the right to name the IPv4 Header Security Flag [RFC3514] "the Microsoft Evil bit".
IETFが、彼らが使用するのを選ぶ名前を使用するために購入組織は権利があるのを保証するのを引き受けないという事実がいたずらにつながることができます。 例えば、マイクロソフトの競争相手は「マイクロソフトEvilビット」とIPv4 Header Security Flag[RFC3514]を命名する権利を購入できました。
19. Conclusion
19. 結論
The discussion above has introduced the concept of branding IETF protocols and the associated implications. Clearly there are non- trivial costs to starting up and maintaining such a revenue stream. However, advertising has a long and distinguished history of supporting valuable community services such as free broadcast television and Google.
上の議論はIETFプロトコルと関連含意に商標を付ける概念を紹介しました。 明確に、そのような収入の流れを立ち上げて、維持することへの非些細なコストがあります。 しかしながら、広告には、無料の放送テレビやGoogleなどの貴重なボランティア活動を支持する長くて顕著な歴史があります。
As branded protocols become established, new protocols will be developed with names conducive to branding. In fact, licensees may initiate new IETF work just to see an appropriate field established. So, besides the economic benefits to the IETF, this initiative may in fact help ensure the IETF is never without work and, thus, self- sustaining and self-perpetuating.
商標を付けられたプロトコルが確立するようになるとき、名前が役に立っていた状態で、新しいプロトコルは商標を付けるのに開発されるでしょう。 事実上、免許所有者は、ただ適切な分野が確立されることを確認するために新しいIETF仕事を開始するかもしれません。 それで、IETFへの経済的利益以外に、事実上、このイニシアチブは、IETFが仕事とその結果、決して自己の支えないのなしでいて、自己を永続させるのを確実にするのを助けるかもしれません。
Falk & Bradner Informational [Page 9] RFC 5241 Naming Rights 1 April 2008
権利を2008年4月1日と命名するフォークとブラドナーの情報[9ページ]のRFC5241
20. References
20. 参照
20.1. Normative References
20.1. 引用規格
[RFC2233] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.
[RFC2233] ポステル、J.、およびJ.レイノルズ、「指示、RFCが書く、」、RFC2223、10月1997日
20.2. Informative References
20.2. 有益な参照
[BUDGET] IETF 2008 budget,
<http://iaoc.ietf.org/documents/2008_Budget_Final.pdf>.
2008年の[BUDGET]IETF予算、<http://iaoc.ietf.org/ドキュメント/2008_Budget_Final.pdf>。
[EKLOR] Eklor, M and A. Launander, "Open outcry auctions with
secret reserve prices: an empirical application to
executive auctions of tenant owner's apartments in
Sweden", Journal of Econometrics, Volume 114, Issue 2,
June 2003, pages 243-260.
[EKLOR] Eklor、M、およびA.Launander、「秘密積立金価格で叫び声オークションを開いてください」 「スウェーデンのテナントのオーナーのアパートの幹部社員オークションへの実証的なアプリケーション」、Econometrics、Volume114、Issue2、2003年6月(243-260ページ)のJournal。
[KOVENOCK] Kovenock, D. & de Vries, C.G., 1995. "The All-Pay Auction
with Complete Information", UFAE and IAE Working Papers
311.95, Unitat de Fonaments de l'Analisi Economica (UAB)
and Institut d'Analisi Economica (CSIC), revised.
[KOVENOCK]Kovenock、D.、およびdeフリーズ、C.G.、1995。 「Complete情報があるAll-賃金Auction」(UFAE、IAE Working Papers311.95、Unitat de Fonaments de l'Analisi Economica(UAB)、およびInstitut d'Analisi Economica(CSIC))は、復習しました。
[MILGROM] Milgrom, P., "Auctions and Bidding: A Primer", Journal of
Economic Perspectives, American Economic Association, vol.
3(3), pages 3-22, Summer 1989.
[ミルグロム]ミルグロム、P.、「オークション、以下を入札すること」。 「Primer」、Economic PerspectivesのJournal、アメリカ経済学会、vol.3(3)、3-22ページ、Summer1989。
[PROTREG] IANA Protocol Registries,
<http://www.iana.org/protocols/>.
[PROTREG]IANAは登録、<http://www.iana.org/protocols/>について議定書の中で述べます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header," RFC
3514, 1 April 2003.
[RFC3514] Bellovin、S.、「IPv4ヘッダーのセキュリティ旗」、RFC3514、2003年4月1日。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変化形式」STD63、RFC3629、11月2003日
[UDRP] ICANN, "Uniform Domain-Name Dispute-Resolution Policy",
<http://www.icann.org/udrp/udrp.htm>.
[UDRP]ICANN、「一定のドメイン名論争の解決方針」、<http://www.icann.org/udrp/udrp.htm>。
[XML2RFC] "A handy little tool", <http://xml.resource.org/>.
[XML2RFC] 「手頃な小さいツール」、<http://xml.resource.org/>。
Falk & Bradner Informational [Page 10] RFC 5241 Naming Rights 1 April 2008
権利を2008年4月1日と命名するフォークとブラドナーの情報[10ページ]のRFC5241
21. Acknowledgments
21. 承認
Craig Milo Rogers receives credit for the idea which lead to this proposal. Allison Mankin contributed to some early discussions of the issues associated with naming rights. Also, thanks to David Parkes for his advice on types of auctions.
クレイグ・ミロ・ロジャースは考えのためにクレジットを受けます(この提案に通じます)。 アリソン・マンキンは名称の権利に関連している問題のいくつかの早めの議論に貢献しました。 また、オークションのタイプに関する彼のアドバイスを求めてデヴィッド・パークスをありがとうございます。
Editors' Addresses
エディタのアドレス
Aaron Falk BBN Technologies 10 Moulton Street Cambridge MA, 02138 USA
アーロンフォークBBN Technologies10モールトン通りケンブリッジ02138MA(米国)
Phone: +1 617 873 2575 EMail: falk@bbn.com
以下に電話をしてください。 +1 2575年の617 873メール: falk@bbn.com
Scott Bradner Harvard University 29 Oxford St. Cambridge MA, 02138 USA
スコットブラドナーハーバード大学29オックスフォードケンブリッジの聖02138MA(米国)
Phone: +1 617 495 3864 EMail: sob@harvard.edu
以下に電話をしてください。 +1 3864年の617 495メール: sob@harvard.edu
Falk & Bradner Informational [Page 11] RFC 5241 Naming Rights 1 April 2008
権利を2008年4月1日と命名するフォークとブラドナーの情報[11ページ]のRFC5241
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Falk & Bradner Informational [Page 12]
フォークとブラドナー情報です。[12ページ]
一覧
スポンサーリンク
