RFC3224 日本語訳
3224 Vendor Extensions for Service Location Protocol, Version 2. E.Guttman. January 2002. (Format: TXT=19618 bytes) (Updates RFC2608) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Guttman Request for Comments: 3224 Sun Microsystems Updates: 2608 January 2002 Category: Standards Track
Guttmanがコメントのために要求するワーキンググループE.をネットワークでつないでください: 3224のサン・マイクロシステムズアップデート: 2608 2002年1月のカテゴリ: 標準化過程
Vendor Extensions for Service Location Protocol, Version 2
サービス位置のプロトコル、バージョン2のためのベンダー拡大
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 (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document specifies how the features of the Service Location Protocol, Version 2 allow for vendor extensibility safely, with no possibility of collisions. The specification introduces a new SLPv2 extension: The Vendor Opaque Extension. While proprietary protocol extensions are not encouraged by IETF standards, it is important that they not hinder interoperability of compliant implementations when they are undertaken. This document udpates RFC 2608, "The Service Location Protocol."
このドキュメントは、Service Locationプロトコルの特徴でありバージョン2がどのように安全にベンダー伸展性を考慮するかを指定します、衝突の可能性なしで。 仕様は新しいSLPv2拡張子を紹介します: ベンダーの不透明な拡大。 固有のプロトコル拡大はIETF規格によって奨励されませんが、引き受けられる場合対応する実装の相互運用性を妨げないのは、重要です。 このドキュメントudpates RFC2608、「サービス位置のプロトコル。」
Table of Contents
目次
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . 2
2.0 Enterprise Numbers . . . . . . . . . . . . . . . . . . . . . 3
3.0 Naming Authorities . . . . . . . . . . . . . . . . . . . . . 3
4.0 Vendor Defined Attributes . . . . . . . . . . . . . . . . . 4
5.0 Vendor Opaque Extension . . . . . . . . . . . . . . . . . . 5
5.1 Vendor Opaque Extension Format . . . . . . . . . . . . . . 6
5.2 Example: Acme Extension for UA Authentication . . . . . . . 6
6.0 Extensions Requiring IETF Action . . . . . . . . . . . . . . 7
7.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
8.0 Security Considerations . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 10
1.0 .34.0ベンダーに当局を任命する序論. . . . . . . . . . . . . . . . . . . . . . . . 2 1.1用語. . . . . . . . . . . . . . . . . . . . . . 2 2.0エンタープライズNo.. . . . . . . . . . . . . . . . . . . . . 3 3.0が属性. . . . . . . . . . . . . . . . . 4 5.0のベンダーの不透明な拡大. . . . . . . . . . . . . . . . . . 5 5.1のベンダーの不明瞭な拡大形式.65.2の例を定義しました: IETF動作. . . . . . . . . . . . . . 7 7.0IANA問題. . . . . . . . . . . . . . . . . . . . 7 8.0セキュリティ問題. . . . . . . . . . . . . . . . . . 8承認を必要とするUA認証. . . . . . . 6 6.0拡張子のための頂上拡大; .8 参照. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8作者のアドレスの.9の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 10
Guttman Standards Track [Page 1] RFC 3224 Vendor Extensions for Service January 2002
Guttman規格は2002年1月にサービスのためのRFC3224ベンダー拡張子を追跡します[1ページ]。
1.0 Introduction
1.0 序論
The Service Location Protocol, Version 2 [1] defines a number of features which are extensible. This document clarifies exactly which mechanisms can be used to that end (Sections 3-5) and which cannot (Section 6). This document updates [1], specifying conventions that ensure the protocol extension mechanisms in the SLPv2 specification will not possibly have ambiguous interpretations.
Service Locationプロトコル、バージョン2[1]は多くの広げることができる特徴を定義します。 このドキュメントはまさにそのために(セクション3-5)どのメカニズムを使用できるか、そして、どれが(セクション6)は使用できないかをはっきりさせます。 このドキュメントは[1]をアップデートします、SLPv2仕様によるプロトコル拡張機能にはあいまいな解釈がことによるとないのを確実にするコンベンションを指定して。
This specification introduces only one new protocol element, the Vendor Opaque Extension. This Extension makes it possible for a vendor to extend SLP independently, once the vendor has registered itself with IANA and obtained an Enterprise Number. This is useful for vendor-specific applications.
この仕様は1個の新しいプロトコル要素、Vendor Opaque Extensionだけを導入します。 このExtensionはベンダーが独自にSLPを広げるのを可能にします、ベンダーがいったんIANAにそれ自体を登録して、エンタープライズNumberを入手すると。 これはベンダー特有のアプリケーションの役に立ちます。
Vendor extensions to standard protocols come at a cost.
標準プロトコルへのベンダー拡大は費用で来ます。
- Vendor extensions occur without review from the community.
They may not make good engineering sense in the context of the
protocol they extend, and the engineers responsible may
discover this too late.
- ベンダー拡大は共同体からレビューなしで起こります。 それらは彼らが広げるプロトコルの文脈での良い工学意味にならないかもしれません、そして、責任がある技術者はあまりに遅く、これを発見するかもしれません。
- Vendor extensions preclude interoperation with compliant but
non-extended implementations. There is a real danger of
incompatibility if different implementations support different
feature sets.
- ベンダー拡張子は言いなりになっていますが、非拡張している実装があるinteroperationを排除します。 異なった実装が異なった特徴セットを支えるなら、不一致の身に迫る危険があります。
- By extending SLPv2 privately, ubiquitous automatic
configuration is impossible, which is the primary benefit of a
standard service discovery framework.
- SLPv2を個人的に広げることによって、遍在している自動構成は不可能です(標準のサービス発見フレームワークの主要便益です)。
For these reasons, registration of service templates with IANA is strongly encouraged! This process is easy and has proved to be rapid (taking less than 2 weeks in most cases).
これらの理由で、IANAとのサービステンプレートの登録は強く奨励されます! このプロセスは、簡単であり、急速であると判明しました(多くの場合、2週間未満かかって)。
1.1 Terminology
1.1 用語
In this document, the key words "MAY", "MUST", "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [2].
そして、キーワード「5月」、“MUST"、「必須NOT」、本書では「任意」の、そして、「お勧め」の“SHOULD"、「」、[2]で説明されるように解釈されることになっているべきになってください。
Service Location Protocol terminology is defined in [1]. IANA registration terminology is defined in [5].
サービスLocationプロトコル用語は[1]で定義されます。 IANA登録用語は[5]で定義されます。
Guttman Standards Track [Page 2] RFC 3224 Vendor Extensions for Service January 2002
Guttman規格は2002年1月にサービスのためのRFC3224ベンダー拡張子を追跡します[2ページ]。
2.0 Enterprise Number
2.0 エンタープライズ番号
Enterprise Numbers are used to distinguish different vendors in IETF protocols. Vendor Extensions to SLPv2 SHOULD use these values to avoid any possibility of a name space collision. Each vendor is responsible for ensuring that vendor extensions under their own authority are non-conflicting.
エンタープライズ民数記は、IETFプロトコルで異なったベンダーを区別するのに使用されます。 SLPv2 SHOULDへのベンダーExtensionsは、名前宇宙衝突のどんな可能性も避けるのにこれらの値を使用します。 それら自身の権威の下におけるベンダー拡大が非闘争であることを確実にするのにそれぞれのベンダーは責任があります。
IANA maintains a repository of all 'SMI Network Management Private Enterprise Codes,' whose prefix is iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). The number which follows is unique and may be registered by an on-line form [3].
IANAが接頭語がiso.org.dod.internet.private.enterpriseであるすべての'SMI Network Management兵士のエンタープライズCodes'の倉庫を維持する、(1.3 .6 .1 .4 .1)。 続く数は、ユニークであり、オンラインフォーム[3]によって示されるかもしれません。
The complete up-to-date list of Enterprise Numbers is maintained by IANA [3].
エンタープライズ民数記の完全な最新のリストはIANA[3]によって維持されます。
3.0 Naming Authorities
3.0当局を任命すること。
Naming Authorities are defined by SLPv2 [1] as an agency or group which catalogues Service Types and attributes.
命名AuthoritiesはSLPv2[1]によってService Typesと属性をカタログに載せる政府機関かグループと定義されます。
A Service Type is a string representing a service which can be discovered by SLPv2. Attributes may be associated with a particular Service Type which is advertised by SLPv2.
Service TypeはSLPv2が発見できるサービスを表すストリングです。 属性はSLPv2によって広告に掲載されている特定のService Typeに関連しているかもしれません。
Service Type strings and service attributes may be registered with IANA by creating a Service Template [4]. The template is included in an internet draft and an email message is sent to srvloc- list@iana.org requesting that the template be included in the Service Template registry. In this case, the naming authority for the service type is IANA.
サービスTypeストリングとサービス属性は、Service Template[4]を作成することによって、IANAに示されるかもしれません。 インターネット草稿でテンプレートを含めます、そして、テンプレートがService Template登録に含まれているよう要求するsrvloc list@iana.org にメールメッセージを送ります。 この場合、サービスタイプのための命名権威はIANAです。
It is also possible for a Vendor to create their own naming authority. In this case, any service type or attribute may be used. SLPv2 allows arbitrary naming authorities to coexist. To use an explicit naming authority, a vendor simply employs their Enterprise Number as a naming authority. For example, for the following (fictitious) Enterprise Number
また、Vendorが、それら自身が権威を命名するのを作成するのも、可能です。 この場合、どんなサービスタイプや属性も使用されるかもしれません。 SLPv2は任意の命名当局を共存させます。 明白な命名権威を使用するために、ベンダーは命名権威として単にそれらのエンタープライズNumberを使います。 例えば以下の(架空)のエンタープライズNumber
9999 Acme, Inc. Erik Guttman femur@example.com
9999年の頂上Inc.エリックGuttman femur@example.com
the Naming Authority string to use would be "9999". A service: URL which used this Naming Authority to advertise a Roadrunner Detector service could look like
使用するNaming Authorityストリングは「9999」でしょう。 サービス: Roadrunner Detectorサービスの広告を出すのにこのNaming Authorityを使用したURLに似ることができました。
service:roadrunner-detector.9999://example.com:9341
サービス: ミチバシリ探知器.9999://example.com: 9341
Guttman Standards Track [Page 3] RFC 3224 Vendor Extensions for Service January 2002
Guttman規格は2002年1月にサービスのためのRFC3224ベンダー拡張子を追跡します[3ページ]。
Service types which are defined under a naming authority based on an Enterprise Number are guaranteed not to conflict with other service type strings which mean something entirely different. That is also true of attributes defined for service types defined under a naming authority.
エンタープライズNumberに基づく命名権威の下で定義されるサービスタイプは、完全に異なった何かを意味する他のサービスタイプストリングと衝突しないように保証されます。 また、それも命名権威の下で定義されたサービスタイプのために定義された属性に関して本当です。
To create a safe naming authority with no possibility of name collisions, a vendor SHOULD use their Enterprise Number as a naming authority.
名前衝突、ベンダーの可能性なしで安全な命名権威を作成するために、SHOULDは命名権威としてそれらのエンタープライズNumberを使用します。
4.0 Vendor Defined Attributes
4.0ベンダーは属性を定義しました。
SLPv2 [1] suggests that
SLPv2[1]はそれを勧めます。
Non-standard attribute names SHOULD begin with "x-", because no
standard attribute name will ever have those initial characters.
どんな標準の属性名にもそれらの初期のキャラクタがないのでSHOULDが「x」で始める標準的でない属性名。
It is possible that two non-standard attributes will conflict that both use the "x-" prefix notation. For that reason, vendors SHOULD use "x-" followed by their Enterprise Number followed by a "-" to guarantee that the non-standard attribute name's interpretation is not ambiguous.
両方が「x」前置表記法を使用するのは、2つの標準的でない属性が闘争するのが可能です。 その理由で、ベンダーSHOULD使用「x」は「-」があとに続いた、標準的でない属性名前の解釈があいまいでないことを保証したそれらのエンタープライズNumberで続きました。
For example, Acme, Inc.'s Enterprise Number is 9999. Say the Service Template for NetHive (a fictitious game) was:
例えば、Acme Inc.のエンタープライズNumberは9999です。 NetHive(架空のゲーム)のためのService Templateは以下の通りであったと言ってください。
------------------------------------------------------------
template-type=NetHive
------------------------------------------------------------ テンプレートタイプはNetHiveと等しいです。
template-version=1.0
テンプレートバージョン= 1.0
template-description=
The popular NetHive game.
テンプレート記述はポピュラーなNetHiveゲームと等しいです。
template-url-syntax=
url-path = ; There is no path for a NetHive service URL.
テンプレート-url構文はurl-経路=と等しいです。 NetHiveサービスURLのための経路が全くありません。
features= string M O
# The list of optional features the NetHive server supports.
secure session, fast mode
#任意のリストはNetHiveサーバサポートを特徴とします。特徴=がM Oを結ぶ、セッション、速いモードを保証してください。
current-users= string M
# The list of users currently playing
------------------------------------------------------------
現在のユーザがストリングMと等しい、#ユーザーズ・リストは現在、プレーします。------------------------------------------------------------
Acme's server advertises a feature which is not on the list of standard features, "x-9999-cheat-mode". Only an Acme client would request this attribute to discover servers, since it is not standard.
頂上のサーバは標準装備のリスト、「x9999はモードをだますところ」にない特徴の広告を出します。 Acmeクライアントだけが、それが標準でないのでサーバを発見するようこの属性に要求するでしょう。
Guttman Standards Track [Page 4] RFC 3224 Vendor Extensions for Service January 2002
Guttman規格は2002年1月にサービスのためのRFC3224ベンダー拡張子を追跡します[4ページ]。
5.0 Vendor Opaque Extension
5.0 ベンダーの不透明な拡大
SLPv2 [1] defines a protocol extensibility mechanism. SLPv2 Extensions are added at the end of a message and have the following format:
SLPv2[1]はプロトコル伸展性メカニズムを定義します。 SLPv2 Extensionsはメッセージの終わりで加えられて、以下の書式を持っています:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension ID | Next Extension Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset, contd.| Extension Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡大ID| 次の拡大は相殺されました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | contd| オフセット、拡大Data/+++++++++++++++++++++++++++++++++
The format of the Extension Data depends on the Extension ID. Refer to [4] for a full description of different mechanisms available for registration of values with IANA.
Extension Dataの形式はExtension IDに依存します。 IANAとの値の登録に利用可能な異なったメカニズムの余すところのない解説のための[4]を参照してください。
SLPv2 may be extended in any of three ways.
SLPv2は3つの方法について少しも広げられるかもしれません。
(1) Anyone may request the designated expert for SLP to register a
new extension ID with IANA. Send requests to the
svrloc-list@iana.org.
(1) SLPが新しい拡大IDをIANAに登録するように、だれでも指定された専門家を要求するかもしれません。 要求を svrloc-list@iana.org に送ってください。
It is recommended that an internet draft specifying this
extension be published, with the intention of publishing the
document as an Informational RFC. This way others can use the
extension as well. This is not a 'vendor extension' - rather
this is the preferred way of extending the protocol in a vendor
neutral manner.
この拡大を指定するインターネット草稿が発表されるのは、お勧めです、Informational RFCとしてドキュメントを発表するという意志で。 このように、他のものはまた、拡張子を使用できます。 これは'ベンダー拡大'ではありません--むしろこれはベンダーの公平無私の方法でプロトコルを広げる都合のよい方法です。
If no specification is published and the extension is intended
for vendor specific use only - the 'Vendor Extension' option
below probably makes more sense than assigning an extension ID.
--仕様が全く発表されないで、拡大がベンダー特定的用法だけのために意図するなら以下での'ベンダーExtension'オプションはたぶん拡大IDを割り当てるより多くの意味になります。
(2) An experimental extension may be done using the range 0x8000 to
0x8FFF. There is always the risk, however, that another vendor
will use the same ID, since these IDs are not registered.
(2) 実験的な拡大は範囲0x8000を0x8FFFに使用し終わるかもしれません。 危険がいつもあって、しかしながら、これらのID以来別のベンダーが同じIDを使用するのは、登録されていません。
(3) A Vendor Extension may be used. This extension allows a Vendor
to define their own extensions which are guaranteed to have a
unique interpretation. It is OPTIONAL to implement.
(3) Vendor Extensionは使用されるかもしれません。 この拡大で、Vendorはユニークな解釈を持つために保証されるそれら自身の拡大を定義できます。 それは道具へのOPTIONALです。
Guttman Standards Track [Page 5] RFC 3224 Vendor Extensions for Service January 2002
Guttman規格は2002年1月にサービスのためのRFC3224ベンダー拡張子を追跡します[5ページ]。
5.1. Vendor Opaque Extension Format
5.1. ベンダーの不透明な拡大形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension ID = 0x0003 | Next Extension Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset, contd.| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent. #, contd.| Extension Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡大ID=0x0003| 次の拡大は相殺されました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オフセット、contd| エンタープライズNumber| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ent。 #, contd| 拡大Data/+++++++++++++++++++++++++++++++++
The Enterprise Number is included in the Extension as a 4 byte unsigned integer value. The Extension Data following is guaranteed to have an unambiguous interpretation determined by the vendor.
エンタープライズNumberは4バイトの符号のない整数値としてExtensionに含まれています。 次の事柄が保証されるExtension Dataはベンダーで決定している明白な解釈を持っています。
5.2 Example: Acme Extension for UA Authentication
5.2の例: UA認証のための頂上拡大
The Acme Corporation, whose Enterprise Number is 9999, can define an extension to SLP. In this example, Acme creates one such extension to create an application level access control to service information. This would allow replies to be sent only to clients who could authenticate themselves.
Acme社(エンタープライズNumberは9999である)は拡大をSLPと定義できます。 この例では、Acmeは、アプリケーションレベルアクセス制御をサービス情報に作成するためにそのような拡大の1つを作成します。 これは、回答が自分たちを認証できたクライアントだけに送られるのを許容するでしょう。
The engineers at Acme give the Extension Data the following form:
Acmeの技術者は以下の書式をExtension Dataに与えます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ACME Ext ID = 1| Client ID Length | Client ID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |頂上Ext ID=1| クライアントIDの長さ| クライアントID… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 固有識別文字… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACME Ext ID: The ACME engineers decided to define the first byte of their extension data as an extension ID field. In the future, ACME may decide to define more than this extension. Since there is 8 bits in the ID field, ACME can define up to 256 different extensions. If ACME were to omit this field and begin directly with their 'Extension for UA Authentication', they would only be able to define one ACME specific SLP extension. For the 'Extension for UA Authentication,' the ACME Extension ID is set to 1. This ID has to be managed within ACME, to make sure that each new extension they invent has a unique ID assigned to it.
頂上Ext ID: ACME技術者は、彼らの拡大データの最初のバイトを拡大ID分野と定義すると決めました。 将来、ACMEは、この拡大以上を定義すると決めるかもしれません。 8ビットがID分野にあるので、ACMEは最大256の異なった拡大を定義できます。 ACMEがこの分野を省略して、直接それらの'UA Authenticationのための拡大'で始まるなら、彼らは1つのACMEの特定のSLP拡張子しか定義できないでしょうに。 'UA Authenticationのための拡大'において、ACME Extension IDは1に設定されます。 このIDは、彼らが発明するそれぞれの新しい拡大で固有のIDをそれに割り当てるのを確実にするためにACMEの中で管理されなければなりません。
Guttman Standards Track [Page 6] RFC 3224 Vendor Extensions for Service January 2002
Guttman規格は2002年1月にサービスのためのRFC3224ベンダー拡張子を追跡します[6ページ]。
Client ID Length: This declares how many bytes of Client ID data follow.
クライアントIDの長さ: これは、何バイトのClient IDデータが従うと宣言します。
Client ID: The Acme application user ID.
クライアントID: AcmeアプリケーションユーザID。
Timestamp: # of seconds since January 1, 2000, 0:00 GMT.
タイムスタンプ: # 2000年1月1日、グリニッジ標準時0時0分以来の秒について。
Authenticator: a 16 byte MD5 digest [6] calculated on the following data fields, concatenated together
固有識別文字: 16バイトのMD5ダイジェスト[6]は一緒に連結された以下のデータ・フィールドを当てにしました。
- UA request bytes, including the header, but not any extensions.
- UA SECRET PASS PHRASE
- Acme UA Authentication Extension - Client ID
- Acme UA Authentication Extension - Timestamp
- UAはどんな拡大ではなく、ヘッダーも含むバイトを要求します。 - Uaの秘密のパス句--頂上UA認証拡張子--クライアントID--頂上UA認証拡張子--タイムスタンプ
The SA or DA which receives this extension and supports this extension will check if it (1) recognizes the Client ID, (2) has an associated SECRET PASS PHRASE for it, (3) whether upon calculating an MD5 digest over the same data as listed above it arrives at the same Authenticator value as included in the extension. If all 3 of these steps succeed, the UA has been authenticated.
この拡大を受けて、意志がそれであるならチェックするこの拡大に(1)をサポートするSAかDAがClient IDを認識して、(3) それの上にリストアップされている同じデータの上のMD5ダイジェストが拡大における含まれているのと同じAuthenticator値に到着すると見込むか否かに関係なく、(2)はそれのための関連SECRET PASS PHRASEを持っています。 これらのすべての3ステップが成功するなら、UAは認証されました。
Note this example is for explanatory purposes only. It would not work well in practice. It requires a shared secret be configured in SAs and DAs, for every UA. Furthermore, the UA secret pass phrase would be susceptible to a dictionary attack.
この例が説明している目的だけのためのものであることに注意してください。 それは実際にはうまくいかないでしょう。 構成されていて、それはあらゆるUAのためのSAsとDAsで共有秘密キーを必要とします。 その上、UAの秘密のパス句は辞書攻撃に影響されやすいでしょう。
6.0 Extensions Requiring IETF Action
6.0 IETF動作を必要とする拡張子
Modification or extension of any feature of SLPv2 whatsoever, aside from those listed in Sections 3-5 of this document, requires a standards action as defined in [1].
このドキュメントのセクション3-5に記載されたものは別として、全くSLPv2のどんな特徴の変更か拡張子も[1]で定義されるように規格動作を必要とします。
Terminology and procedures for IETF Actions related to registration of IDs with IANA are defined in [5]. Existing SLPv2 extensions assignments are registered with IANA [3].
IANAとのIDの登録に関連するIETF Actionsのための用語と手順は[5]で定義されます。 既存のSLPv2拡大課題はIANA[3]に登録されます。
7.0 IANA Considerations
7.0 IANA問題
This document clarifies procedures described in other documents [1] [4]. The Vendor Opaque Extension ID has already been registered [3]. No additional IANA action is required for publication of this document.
このドキュメントは他のドキュメント[1][4]で説明された手順をはっきりさせます。 既にVendor Opaque Extension IDを登録してあります。[3]。 どんな追加IANA動作もこのドキュメントの公表に必要ではありません。
Guttman Standards Track [Page 7] RFC 3224 Vendor Extensions for Service January 2002
Guttman規格は2002年1月にサービスのためのRFC3224ベンダー拡張子を追跡します[7ページ]。
8.0 Security Considerations
8.0 セキュリティ問題
Vendor extensions may introduce additional security considerations into SLP.
ベンダー拡大は追加担保問題をSLPに紹介するかもしれません。
This memo describes mechanisms which are standardized elsewhere [1] [4]. The only protocol mechanism described in this document (see Section 5 above) is no less secure than 'private use' extensions defined in SLPv2 [1].
このメモはほかの場所で標準化されるメカニズムについて説明します。[1][4]。 本書では(セクション5が上であることを見る)説明された唯一のプロトコルメカニズムはSLPv2[1]で定義された'私用'拡大ほど安全でないというわけではありません。
The example in Section 5.2 above shows how Vendor Opaque Extensions can be used to include an access control mechanism to SLP so that SAs can enforce an access control policy using an authentication mechanism. This is merely an example and protocol details were intentionally not provided. A vendor could, however, create a mechanism similar to this one and provide additional security services to SLPv2 in the manner indicated in the example.
SAsが認証機構を使用することでアクセス制御方針を実施できるようにSLPにアクセス管理機構を含めるのに使用できます上のセクション5.2の例が、どのようにVendor Opaque Extensionsを示している。 これは単に例です、そして、プロトコル詳細は故意に明らかにされませんでした。 ベンダーは、しかしながら、これと同様の状態でメカニズムを作成して、例で示された方法でSLPv2に対する追加担保サービスを提供できるでしょう。
Acknowledgements
承認
I thank the IESG, for their usual persistence and attention to detail.
私は詳しく述べる彼らの普通の固執と注意についてIESGに感謝します。
References
参照
[1] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Location Protocol, Version 2", RFC 2608, July 1999.
[1] Guttman(E.、パーキンス、C.、Veizades、J.、およびM.日)は「1999年7月にRFC2608を位置のプロトコル、バージョン2インチ調整します」。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] http://www.iana.org/numbers.html
[3] http://www.iana.org/numbers.html
[4] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
URLs", RFC 2609, July 1999.
[4] Guttman(E.、パーキンス、C.、およびJ.ケンフ)が「テンプレートとURLを調整する」、RFC2609、7月1999日
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[5]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[6] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
Guttman Standards Track [Page 8] RFC 3224 Vendor Extensions for Service January 2002
Guttman規格は2002年1月にサービスのためのRFC3224ベンダー拡張子を追跡します[8ページ]。
Author's Address
作者のアドレス
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
エリックGuttmanサン・マイクロシステムズEichhoelzelstr。 7 74915Waibstadtドイツ
Phone: +49 7263 911 701 Messages: +49 6221 356 202 EMail: erik.guttman@sun.com
以下に電話をしてください。 +49 7263 911 701のメッセージ: +49 6221 356 202はメールされます: erik.guttman@sun.com
Guttman Standards Track [Page 9] RFC 3224 Vendor Extensions for Service January 2002
Guttman規格は2002年1月にサービスのためのRFC3224ベンダー拡張子を追跡します[9ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Guttman Standards Track [Page 10]
Guttman標準化過程[10ページ]
一覧
スポンサーリンク
