[要約] RFC 6760は、AppleTalkの名前バインディングプロトコル（NBP）を置き換えるためのプロトコルの要件を定義しています。このRFCの目的は、AppleTalkのNBPをより効率的かつ拡張可能なプロトコルで置き換えることです。
Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 6760 M. Krochmal
Category: Informational Apple Inc.
ISSN: 2070-1721 February 2013
Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)
AppleTalk Name Binding Protocol（NBP）を置き換えるプロトコルの要件
Abstract
概要
One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was to retire AppleTalk and the AppleTalk Name Binding Protocol (NBP) and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP and outlines the properties required of an IP-based replacement.
マルチキャストDNS（mDNS）とDNSベースのサービスディスカバリ（DNS-SD）の作成者の目標の1つは、AppleTalkとAppleTalk Name Binding Protocol（NBP）を廃止し、それらをIPベースのソリューションに置き換えることでした。このドキュメントでは、AppleTalk NBPの機能の概要と、IPベースの交換に必要なプロパティの概要について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6760.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6760で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Zero Configuration Networking ...................................4
3. Requirements ....................................................4
3.1. Name-to-Address Mapping ....................................5
3.2. Name Services, Not Hardware ................................5
3.3. Address Services, Not Hardware -- or -- Escape the
Tyranny of Well-Known Ports ................................6
3.4. Typed Name Space ...........................................8
3.5. User-Friendly Names ........................................9
3.6. Zeroconf Operation .........................................9
3.7. Name Space Management -- or -- Name Conflict Detection ....10
3.8. Late Binding ..............................................11
3.9. Simplicity ................................................11
3.10. Network Browsing .........................................11
3.11. Browsing and Registration Guidance .......................12
3.12. Power Management Support .................................12
3.13. Protocol Agnostic ........................................13
3.14. Distributed Cache Coherency Protocol .....................13
3.15. Immediate and Ongoing Information Presentation ...........13
4. Existing Protocols .............................................14
5. IPv6 Considerations ............................................14
6. Security Considerations ........................................14
7. Informative References .........................................15
An important goal of the participants working on Zeroconf, Multicast DNS, and DNS-Based Service Discovery was to provide a viable IP-based replacement for AppleTalk and the AppleTalk Name Binding Protocol (NBP).
Zeroconf、マルチキャストDNS、およびDNSベースのサービスディスカバリに取り組む参加者の重要な目標は、AppleTalkおよびAppleTalk Name Binding Protocol（NBP）の実行可能なIPベースの代替を提供することでした。
There are many who are experts in the Domain Name System (DNS) who know nothing about the AppleTalk Name Binding Protocol (NBP). Without some background on how AppleTalk and NBP worked, it may be difficult to understand the reasoning and motivations that led to the design decisions in Multicast DNS and DNS-Based Service Discovery.
AppleTalk Name Binding Protocol（NBP）について何も知らないドメインネームシステム（DNS）の専門家はたくさんいます。 AppleTalkとNBPがどのように機能したかについての背景がないと、マルチキャストDNSとDNSベースのサービスディスカバリの設計決定につながった理由と動機を理解するのが難しい場合があります。
This document seeks to remedy this problem by clearly stating the requirements for an IP-based replacement for AppleTalk and NBP. Replacing NBP was not the sole goal of Multicast DNS; therefore, these requirements are not the sole design considerations. However, replacing NBP was a major motivation behind the work in Multicast DNS.
このドキュメントでは、AppleTalkおよびNBPのIPベースの交換の要件を明確に記載することにより、この問題の解決を目指しています。 NBPの置き換えは、マルチキャストDNSの唯一の目標ではありませんでした。したがって、これらの要件だけが設計上の考慮事項ではありません。ただし、NBPの置き換えは、マルチキャストDNSでの作業の背後にある大きな動機でした。
In most cases, the requirements presented in this document are simply a restatement of what AppleTalk NBP currently does. However, this document is not restricted to describing only what NBP currently does. Achieving at least equivalent functionality to NBP is a necessary but not sufficient condition for a viable replacement. In some cases, the requirements for a viable IP-based replacement go beyond NBP. For example, AppleTalk NBP uses Apple Extended ASCII for its character set. It is clear that an IP-based replacement being designed today should use Unicode, in the form of UTF-8 [RFC3629]. AppleTalk NBP has a reputation, partially deserved, for being too 'chatty' on the network. An IP-based replacement should not have this same failing. The intent is to learn from NBP and build a superset of its functionality, not to replicate it precisely with all the same flaws.
ほとんどの場合、このドキュメントに示されている要件は、AppleTalk NBPが現在行っていることを単に言い換えたものです。ただし、このドキュメントは、NBPが現在行っていることだけを説明することに限定されません。 NBPと少なくとも同等の機能を実現することは、実行可能な置き換えのために必要ですが、十分ではありません。場合によっては、実行可能なIPベースの交換の要件がNBPを超えることがあります。たとえば、AppleTalk NBPは文字セットにApple Extended ASCIIを使用します。今日設計されているIPベースの置き換えでは、UTF-8 [RFC3629]の形式のUnicodeを使用する必要があることは明らかです。 AppleTalk NBPには、ネットワーク上であまりにも「おしゃべり」であるという評判があります。 IPベースの交換でこれと同じ障害が発生することはありません。その意図は、NBPから学び、その機能のスーパーセットを構築することであり、まったく同じ欠陥で正確に複製することではありません。
The protocols specified in "Multicast DNS" [RFC6762] and "DNS-Based Service Discovery" [RFC6763], taken together, describe a solution that meets these requirements. This document is written, in part, in response to requests for more background information explaining the rationale behind the design of those protocols.
「マルチキャストDNS」[RFC6762]および「DNSベースのサービスディスカバリ」[RFC6763]で指定されているプロトコルは、まとめて、これらの要件を満たすソリューションを示しています。このドキュメントは、一部、これらのプロトコルの設計の背後にある理論的根拠を説明するより多くの背景情報の要求に応えて書かれています。
Historically, TCP/IP networking required configuration, either in the form of manual configuration by a human operator or in the form of automated configuration provided by a DHCP server [RFC2131].
歴史的に、TCP / IPネットワーキングは、人間のオペレーターによる手動構成の形式、またはDHCPサーバーが提供する自動構成の形式[RFC2131]のいずれかで構成を必要としました。
One of the characteristics of AppleTalk was that it could operate without any dependency on manual configuration or a network service to provide automated configuration. An AppleTalk network could be as small as just two laptop computers connected via an Ethernet cable (or wirelessly).
AppleTalkの特徴の1つは、手動構成やネットワークサービスに依存せずに動作し、自動構成を提供できることです。 AppleTalkネットワークは、イーサネットケーブルを介して（またはワイヤレスで）接続されている2台のラップトップコンピュータと同じくらい小さい場合があります。
IP now has self-assigned link-local addresses [RFC3927] [RFC4862], which enable IP-based networking in the absence of external configuration. What remains is the need for Zero Configuration name-to-address translation and Zero Configuration service discovery, both capabilities that AppleTalk NBP offered.
現在、IPには自己割り当てのリンクローカルアドレス[RFC3927] [RFC4862]があり、外部設定なしでIPベースのネットワーキングが可能になります。残っているのは、ゼロ構成の名前からアドレスへの変換とゼロ構成サービスの検出の両方の必要性であり、どちらもAppleTalk NBPが提供した機能です。
It is not necessarily the case that Zero Configuration Networking protocols will always be used in all three areas (addressing, naming, and service discovery) simultaneously on any given network. For example, even on networks with a DHCP server to provide address configuration, users may still use Zero Configuration protocols for name-to-address translation and service discovery. Indeed, on a single network, users may use conventional Unicast DNS for looking up the addresses of Internet web sites while at the same time using Multicast DNS for looking up the addresses of peers on the local link. Therefore, Zero Configuration Networking protocols must coexist peacefully with conventional configured IP networking when used together on the same network.
ゼロ構成ネットワーキングプロトコルが常に特定のネットワークの3つすべての領域（アドレッシング、ネーミング、およびサービスディスカバリ）で同時に使用されるとは限りません。たとえば、DHCPサーバーを使用してアドレス構成を提供するネットワーク上でも、ユーザーは名前からアドレスへの変換とサービス検出にZero Configurationプロトコルを使用できます。実際、単一のネットワークでは、ユーザーは従来のユニキャストDNSを使用してインターネットWebサイトのアドレスを検索すると同時に、マルチキャストDNSを使用してローカルリンク上のピアのアドレスを検索することができます。したがって、Zero Configuration Networkingプロトコルは、同じネットワークで一緒に使用される場合、従来の構成済みIPネットワークと平和的に共存する必要があります。
Networks change state over time. Hosts and services may come and go. Connectivity, addresses, and names change. In a manually configured network, a human operator can remedy errors when they arise. In a Zero Configuration Network, no such human operator is available to diagnose and troubleshoot problems, so Zero Configuration protocols need to be self-correcting, automatically accommodating changing network conditions, continually converging to correctness in the absence of human intervention to manually rectify errors.
ネットワークは時間とともに状態が変化します。ホストとサービスは行き来するかもしれません。接続、アドレス、および名前が変更されます。手動で構成されたネットワークでは、人間のオペレーターはエラーが発生したときにそれを修正できます。ゼロ構成ネットワークでは、そのような人間のオペレーターが問題の診断とトラブルシューティングに利用できないため、ゼロ構成プロトコルは自己修正し、変化するネットワーク条件に自動的に対応し、手動でエラーを修正するための人間の介入がなくても継続的に正確に収束する必要があります。
This section lists the 15 requirements for an IP-based replacement for AppleTalk NBP.
このセクションでは、AppleTalk NBPのIPベースの置き換えに関する15の要件を示します。
NBP's primary function is translating names to addresses.
NBPの主な機能は、名前をアドレスに変換することです。
NBP stands for Name Binding Protocol, not Network Browsing Protocol. Many people know NBP only as "that thing that used to let you browse the network in the old Macintosh Chooser". While browsing is an important facility of NBP, it is secondary to NBP's primary function of translating names to addresses.
NBPはネットワークブラウズプロトコルではなく、名前バインディングプロトコルの略です。多くの人々は、NBPを「古いMacintoshセレクターでネットワークを閲覧できるようにするために使用されていたもの」としてのみ知っています。ブラウジングはNBPの重要な機能ですが、名前をアドレスに変換するNBPの主要な機能に次ぐものです。
Every time a user prints using AppleTalk, the printing software takes the name of the currently selected printer, looks up the current AppleTalk address associated with that named service, and establishes a connection to that service on the network. The user may invoke NBP's browsing capability once, when first selecting the desired printer in the Chooser, but after that, every time something is printed, it is a simple efficient name-to-address lookup that is being performed, not a full-fledged browsing operation.
ユーザーがAppleTalkを使用して印刷するたびに、印刷ソフトウェアは現在選択されているプリンターの名前を取得し、その名前付きサービスに関連付けられている現在のAppleTalkアドレスを検索して、ネットワーク上のそのサービスへの接続を確立します。ユーザーは、セレクターで目的のプリンターを最初に選択するときに、NBPのブラウジング機能を1回呼び出すことができますが、その後、何かが印刷されるたびに、本格的な名前からアドレスへのルックアップが実行されます。ブラウジング操作。
Any NBP replacement needs to support, as its primary function, an efficient name-to-address lookup operation.
NBPの置き換えは、その主要な機能として、効率的な名前からアドレスへのルックアップ操作をサポートする必要があります。
The primary named entities in NBP are services, not "hosts", "machines", "devices", or pieces of hardware of any kind. This concept is more subtle than it may seem at first, so it bears some discussion.
NBPの主要な名前付きエンティティはサービスであり、「ホスト」、「マシン」、「デバイス」、またはあらゆる種類のハードウェアの一部ではありません。この概念は、最初に思われるよりも微妙なので、ある程度の議論が必要です。
The AppleTalk NBP philosophy is that naming a piece of hardware on the network is of little use if you can't communicate with that piece of hardware. To communicate with a piece of hardware, there needs to be a piece of software running on that hardware that sends and receives network packets conforming to some specific protocol. This means that whenever you communicate with a machine, you are really communicating with some piece of software on that machine. Even if you just 'ping' a machine to see if it is responding, it is not really the machine that you are 'pinging', it is the software on that machine that generates ICMP Echo Responses [RFC792].
AppleTalk NBPの哲学は、ネットワーク上のハードウェアの一部に名前を付けても、そのハードウェアと通信できない場合はほとんど役に立たないということです。ハードウェアの一部と通信するには、特定のプロトコルに準拠するネットワークパケットを送受信するソフトウェアがそのハードウェアで実行されている必要があります。これは、マシンと通信するときはいつでも、そのマシン上のソフトウェアの一部と実際に通信していることを意味します。マシンに「ping」して応答があるかどうかを確認しても、実際に「ping」しているのはマシンではなく、ICMPエコー応答を生成するのはそのマシン上のソフトウェアです[RFC792]。
Consequently, this means that the only things worth naming are the software entities with which you can communicate. A user who wants to use a print server or a file server needn't care about what hardware implements those services. There may be a single machine hosting both services, or there may be two separate machines. The end user doesn't need to care.
したがって、これは、名前を付ける価値があるのは、通信できるソフトウェアエンティティだけであることを意味します。プリントサーバーまたはファイルサーバーを使用するユーザーは、これらのサービスを実装するハードウェアを気にする必要はありません。両方のサービスをホストする単一のマシンがある場合と、2つの別個のマシンがある場合があります。エンドユーザーは気にする必要はありません。
The one exception to this is network managers, who may want to name physical hardware for the purpose of tracking physical inventory. However, even this can be recast into a service-oriented view of the world by saying that what you're naming is not the hardware, but the ICMP Echo Responder that runs (or is assumed to be running) on every piece of IP hardware.
これに対する1つの例外は、ネットワークマネージャーです。ネットワークマネージャーは、物理的なインベントリを追跡する目的で物理的なハードウェアに名前を付けることができます。ただし、名前を付けているのはハードウェアではなく、すべてのIPハードウェアで実行されている（または実行されていると想定される）ICMPエコーレスポンダーであると言うことで、サービス指向の世界観に再キャストすることもできます。 。
3.3. Address Services, Not Hardware -- or -- Escape the Tyranny of Well-Known Ports
3.3. ハードウェアではなくアドレスサービス-または-既知のポートの専制政治からの脱出
The reader may argue that DNS already supports the philosophy of naming services instead of hosts. When we see names like "www.example.com.", "pop.example.com.", "smtp.example.com.", "news.example.com.", and "time.example.com.", we do not assume that those names necessarily refer to different hosts. They are clearly intended to be logical service names and could, in fact, all resolve to the same IP address.
読者は、DNSがホストの代わりにネームサービスの哲学をすでにサポートしていると主張するかもしれません。 「www.example.com。」、「pop.example.com。」、「smtp.example.com。」、「news.example.com。」、「time.example.com」などの名前が表示された場合、これらの名前が必ずしも異なるホストを参照しているとは想定していません。それらは明らかに論理的なサービス名であることが意図されており、実際にはすべて同じIPアドレスに解決される可能性があります。
The shortcoming here is that although the names are clearly logical service names, the result today of doing a conventional ("A" or "AAAA") DNS lookup for those names gives you only the IP address of the hardware where the service is located. To communicate with the desired service, you also need to know the port number at which the service can be reached, not just the IP address.
ここでの欠点は、名前が明らかに論理的なサービス名であるにもかかわらず、これらの名前に対して従来の（「A」または「AAAA」）DNSルックアップを実行した結果、サービスが配置されているハードウェアのIPアドレスしか得られないことです。目的のサービスと通信するには、IPアドレスだけでなく、サービスに到達できるポート番号も知っている必要があります。
This means that the port number has to be communicated out-of-band, in some other way. One way is for the port number to be a specific well-known constant for any given protocol. This makes it hard to run more than one instance of a service on a single piece of hardware. Another way is for the user to explicitly type in the port number, for example, "www.example.com.:8080" instead of "www.example.com.", but needing to know and type in a port number is as ugly and fragile as needing to know and type in an IP address.
つまり、ポート番号は、他の方法で帯域外で通信する必要があります。 1つの方法は、ポート番号を特定のプロトコルの特定の既知の定数にすることです。これにより、単一のハードウェア上でサービスの複数のインスタンスを実行することが難しくなります。別の方法は、ユーザーがポート番号を明示的に入力することです。たとえば、「www.example.com。」の代わりに「www.example.com.:8080」を使用しますが、ポート番号を知って入力する必要があります。 IPアドレスを知って入力する必要があるため、醜く壊れやすい。
Another aspect of the difficulty of running more than one instance of a service on a single piece of hardware is that it forces application programmers to write their own demultiplexing capability. AppleTalk did not suffer this limitation. If an AppleTalk print server offered three print queues, each print queue ran as its own independent service, listening on its own port number (called a socket number in AppleTalk terminology), each advertised as a separate, independently named NBP entity. When a client looks up the address of that named NBP entity, the reply encodes not only on which net and subnet the service resides, and on which host on that subnet (like an IP address does), but also on which socket number (port number) within that host. In contrast, if an lpr print server offers three print queues, all three print queues are typically reached through the same well-known port number (515), and then the lpr protocol has to use its own demultiplexing capability (the print queue name) in order to determine which print queue is sought. This makes it especially difficult to run two different pieces of print queue software from different vendors on the same machine, because they cannot both listen on the same well-known port.
1つのハードウェア上でサービスの複数のインスタンスを実行することの難しさのもう1つの側面は、アプリケーションプログラマーが独自の逆多重化機能を作成する必要があることです。 AppleTalkはこの制限を受けませんでした。 AppleTalkプリントサーバーが3つのプリントキューを提供した場合、各プリントキューは独自の独立したサービスとして実行され、独自のポート番号（AppleTalk用語ではソケット番号と呼ばれます）をリッスンし、それぞれ独立した、独立した名前のNBPエンティティとして通知されます。クライアントがその名前付きNBPエンティティのアドレスを検索すると、応答はサービスが存在するネットとサブネット、およびそのサブネット上のどのホスト（IPアドレスのように）だけでなく、どのソケット番号（ポート）にもエンコードします番号）そのホスト内。対照的に、lprプリントサーバーが3つのプリントキューを提供する場合、3つのプリントキューはすべて同じウェルノウンポート番号（515）を介して到達し、lprプロトコルは独自の逆多重化機能（プリントキュー名）を使用する必要があります。どの印刷キューを探すかを決定するため。これにより、異なるベンダーの2つの異なるプリントキューソフトウェアを同じマシン上で実行することは特に困難になります。これらは両方とも、同じウェルノウンポートでリッスンできないためです。
A similar trick is used in HTTP 1.1, where the "Host" header line is used to allow multiple logical HTTP services to run at the same IP address. Again, this works for a single-vendor solution, but if a user wishes to run multiple web servers (for example, an image server, a database program, an HTTP email access gateway, and a conventional HTTP server) on a single machine, they can't all listen on TCP port 80, the traditional HTTP port.
同様のトリックがHTTP 1.1でも使用されており、「ホスト」ヘッダー行を使用して、複数の論理HTTPサービスを同じIPアドレスで実行できます。繰り返しになりますが、これは単一ベンダーのソリューションで機能しますが、ユーザーが単一のマシンで複数のWebサーバー（たとえば、画像サーバー、データベースプログラム、HTTP電子メールアクセスゲートウェイ、従来のHTTPサーバー）を実行したい場合は、従来のHTTPポートであるTCPポート80ですべてリッスンすることはできません。
Yet another problem of well-known ports is that port numbers are a finite resource. Originally, port numbers 0-255 were reserved for well-known services, and the remaining 99.6% of the port space was free for dynamic allocation [RFC1122]. Since then, the range of "Registered Ports" has crept upwards until today, ports 0-49151 are reserved, and only 25% of the space remains available for dynamic allocation. Even though 65535 may seem like a lot of available port numbers, with the pace of software development today, if every new protocol gets its own private port number, we will eventually run out. To avoid having to do application-level demultiplexing, protocols like the X Window System wisely use a range of port numbers, and let TCP do the demultiplexing for them. The X Window System uses 64 ports, in the range 6000-6063. If every new protocol were to get its own chunk of 64 ports, we would run out even faster.
よく知られたポートのさらに別の問題は、ポート番号が有限のリソースであることです。当初、ポート番号0〜255はウェルノウンサービス用に予約されており、ポート領域の残りの99.6％は動的割り当て用に解放されていました[RFC1122]。それ以来、「登録済みポート」の範囲は今日まで増加してきており、ポート0〜49151は予約されており、動的割り当てに使用できるのはスペースの25％だけです。 65535は利用可能なポート番号のように見えるかもしれませんが、今日のソフトウェア開発のペースでは、すべての新しいプロトコルが独自のプライベートポート番号を取得すると、最終的には不足します。アプリケーションレベルの逆多重化を行わなくても済むように、X Window Systemのようなプロトコルは、ある範囲のポート番号を賢く使用し、TCPにそれらの逆多重化を行わせます。 Xウィンドウシステムは、6000〜6063の範囲の64個のポートを使用します。すべての新しいプロトコルが64ポートの独自のチャンクを取得する場合、さらに速く実行されます。
Any NBP replacement needs to provide, not just the network number, subnet number, and host number within that subnet (i.e., the IP address) but also the port number within that host where the service is located. Furthermore, since many existing IP services such as lpr *do* already use additional application-layer demultiplexing information such as a print queue name, an NBP replacement needs to support this too by including this information as part of the complete package of addressing information provided to the client to enable it to use the service. The NBP replacement needs to name individual print queues as first-class entities in their own right. It is not sufficient merely to name a print server, within which separate print queues can then be found by some other mechanism.
ネットワーク番号、サブネット番号、そのサブネット内のホスト番号（IPアドレスなど）だけでなく、サービスが配置されているそのホスト内のポート番号も提供する必要があります。さらに、lpr * do *などの多くの既存のIPサービスは、印刷キュー名などの追加のアプリケーション層の逆多重化情報をすでに使用しているため、NBPの置き換えでは、提供されるアドレッシング情報の完全なパッケージの一部としてこの情報を含めることで、これもサポートする必要があります。クライアントがサービスを使用できるようにします。 NBPの置き換えでは、個々の印刷キューをそれ自体がファーストクラスのエンティティとして指定する必要があります。プリントサーバーに名前を付けるだけでは十分ではなく、別のプリントキューを他のメカニズムで見つけることができます。
One possible answer here is that an IP-based NBP replacement could use a solution derived from DNS SRV records instead of "A" records, since SRV records *do* provide a port number. However, this alone is not a complete solution, because SRV records cannot tell you an lpr print queue name.
ここで考えられる答えの1つは、SRVレコードはポート番号を提供するため、IPベースのNBPの置き換えでは「A」レコードの代わりにDNS SRVレコードから派生したソリューションを使用できるということです。ただし、SRVレコードはlpr印刷キュー名を通知できないため、これだけでは完全なソリューションではありません。
AppleTalk NBP names are structured names, generally written as:
AppleTalk NBP名は構造化された名前であり、一般的に次のように記述されます。
Name : Type @ Zone
名前：タイプ@ゾーン
Name: The Name is the user-visible name of the service.
名前：名前は、ユーザーに表示されるサービスの名前です。
Type: The Type is an opaque identifier that identifies the service protocol and semantics. The user may think of the Type as identifying the end-user function that the device performs (e.g., "printing"), and for the typical end-user, this may be an adequate mental model, but strictly speaking, from a protocol-design perspective, the Type identifies the semantic application protocol the service speaks: no more, no less. For convenience, the opaque Type identifier is generally constructed using descriptive ASCII text, but this text has no meaning to the protocol, and care should be taken in inferring too much meaning from it. For example, the NBP Service Type "LaserWriter" means "any service that speaks PS/PAP/ATP/DDP (PostScript over AppleTalk Printer Access Protocol over AppleTalk Transaction Protocol over AppleTalk Datagram Delivery Protocol)". It does not necessarily mean an Apple-branded "LaserWriter" printer; nor does the service even have to be a printer. A device that archives documents to digital media could advertise itself as a "LaserWriter", meaning that it speaks PostScript over PAP, not necessarily that it prints that document on paper when it gets it. The end-user never directly sees the Service Type. It is implicit in the user's action; for example, when printing, the printing software knows what protocol(s) it speaks and consequently what Service Type(s) it should be looking for -- the user doesn't have to tell it.
タイプ：タイプは、サービスプロトコルとセマンティクスを識別する不透明な識別子です。ユーザーは、Typeをデバイスが実行するエンドユーザー機能（「印刷」など）を識別するものと考え、一般的なエンドユーザーの場合、これは適切なメンタルモデルですが、厳密にはプロトコルから設計の観点から見ると、Typeはサービスが話すセマンティックアプリケーションプロトコルを識別します。便宜上、不透明なタイプ識別子は通常、説明的なASCIIテキストを使用して構築されますが、このテキストはプロトコルには意味がなく、そこからあまりにも多くの意味を推測するように注意する必要があります。たとえば、NBPサービスタイプ「LaserWriter」は、「PS / PAP / ATP / DDP（AppleTalkプリンタアクセスプロトコル経由のAppleScriptトランザクションプロトコル経由のAppleTalkデータグラム配信プロトコル経由のPostScript）を話すサービス」を意味します。これは、必ずしもAppleブランドの「LaserWriter」プリンタを意味するものではありません。また、サービスはプリンタである必要もありません。ドキュメントをデジタルメディアにアーカイブするデバイスは、それ自体を「LaserWriter」としてアドバタイズできます。つまり、PAPを介してPostScriptを読み上げ、必ずしもドキュメントを受け取ったときに紙に印刷するわけではありません。エンドユーザーがサービスタイプを直接見ることはありません。これは、ユーザーのアクションに暗黙的に含まれています。たとえば、印刷するとき、印刷ソフトウェアはそれが話すプロトコルを知っているため、検索する必要のあるサービスの種類を知っています。ユーザーが指定する必要はありません。
Zone: The Zone is an organizational or geographical grouping of named services. AppleTalk Zones were typically given names like "Engineering", "Sales", or "Building 1, 3rd floor, North". The equivalent concept in DNS could be a subdomain such as "Engineering.example.com.", "Sales.example.com.", or "Building 1, 3rd floor, North.example.com."
ゾーン：ゾーンは、名前付きサービスの組織的または地理的なグループです。 AppleTalkゾーンには通常、「エンジニアリング」、「セールス」、「ビルディング1、3階北」などの名前が付けられています。 DNSの同等の概念は、「Engineering.example.com。」、「Sales.example.com。」、または「Building 1、3階、North.example.com」などのサブドメインです。
Each {Type,Zone} pair defines a name space in which service names can be registered. It is not a name conflict to have a printer called "Sales" and a file server called "Sales", because one is "Sales:LaserWriter@Zone" and the other is "Sales:AFPServer@Zone".
{Type、Zone}の各ペアは、サービス名を登録できる名前空間を定義します。 1つは "Sales：LaserWriter @ Zone"、もう1つは "Sales：AFPServer @ Zone"であるため、 "Sales"というプリンターと "Sales"というファイルサーバーを使用しても名前の競合はありません。
Any NBP replacement needs to provide a mechanism that allows names to be grouped into organizational or geographical "zones", and within each "zone", to provide an independent name space for each service type.
NBPの置き換えでは、名前を組織的または地理的な「ゾーン」にグループ化し、各「ゾーン」内で、サービスタイプごとに独立した名前空間を提供できるメカニズムを提供する必要があります。
When repeatedly typing in names on command-line systems, it is helpful to have names that are short, all lowercase, without spaces or hard-to-type characters.
コマンドラインシステムで名前を繰り返し入力する場合は、スペースや入力しにくい文字を含まない、すべて小文字の名前を使用すると便利です。
Since Service Names are intended to be selected from a list, not repeatedly typed in on a keyboard, there is no reason for them to be restricted so. Users should be able to give their printers names like "Sales", "Marketing", and "3rd Floor Copy Room", not just "printer1.example.com.". Of course, a user is free to name a particular service using only lowercase letters and no spaces if they wish, but they should not be forced to do that.
サービス名は、キーボードから繰り返し入力するのではなく、リストから選択することを目的としているため、そのように制限する必要はありません。ユーザーは、「printer1.example.com。」だけでなく、「Sales」、「Marketing」、「3rd Floor Copy Room」などのプリンタ名を指定できる必要があります。もちろん、ユーザーは必要に応じて、小文字のみを使用し、スペースを使用せずに特定のサービスに自由に名前を付けることができますが、そうするように強制されるべきではありません。
Any NBP replacement needs to support a full range of rich text characters, including uppercase, lowercase, spaces, accented characters, and so on. The correct solution is likely to be UTF-8 Unicode [RFC3629].
NBPの置換では、大文字、小文字、スペース、アクセント付き文字など、リッチテキスト文字の全範囲をサポートする必要があります。正しい解決策はおそらくUTF-8 Unicode [RFC3629]です。
Note that this requirement for user-friendly rich-text names applies equally to the zones (domains) in which services are registered and discovered.
このユーザーフレンドリーなリッチテキスト名の要件は、サービスが登録および検出されるゾーン（ドメイン）にも同様に適用されることに注意してください。
Note that although the characters ':' and '@' are used when writing AppleTalk NBP names, they are simply a notational convenience in written text. In the on-the-wire protocol and in the software data structures, NBP Name, Type, and Zone strings are all allowed to contain almost any character, including ':' and '@'. The naming scheme provided by an NBP replacement must allow the use of any desired characters in service names, including dots ('.'), spaces, percent signs, etc.
AppleTalk NBP名を書くときに文字「：」と「@」が使用されますが、これらは単にテキストを表記する際の表記上の便宜であることに注意してください。オンザワイヤプロトコルおよびソフトウェアデータ構造では、NBPの名前、タイプ、およびゾーンの文字列に、「：」や「@」などのほとんどすべての文字を含めることができます。 NBPの置き換えによって提供される命名規則では、ドット（ '。'）、スペース、パーセント記号などを含む、サービス名での任意の文字の使用を許可する必要があります。
AppleTalk NBP is self-configuring. On a network of just two hosts, they communicate peer-to-peer using multicast. On a large managed network, AppleTalk routers automatically perform an aggregation function, allowing name lookups to be performed via unicast to a service running on the router, instead of by flooding the entire network with multicast packets to every host.
AppleTalk NBPは自己構成型です。 2つのホストのみのネットワークでは、マルチキャストを使用してピアツーピアで通信します。大規模な管理対象ネットワークでは、AppleTalkルーターは自動的に集約機能を実行し、ネットワーク全体をマルチキャストパケットで各ホストにフラッディングするのではなく、ルーターで実行されているサービスへのユニキャストを介して名前の検索を実行できます。
Any NBP replacement needs to be able to operate in the absence of external network infrastructure. However, this should not be the only mode of operation. In larger managed networks, it should also be possible to take advantage of appropriate external network infrastructure when present, to perform queries via unicast instead of multicast.
NBPの交換は、外部ネットワークインフラストラクチャがなくても機能する必要があります。ただし、これが唯一の動作モードではありません。大規模な管理対象ネットワークでは、適切な外部ネットワークインフラストラクチャが存在する場合、それを利用して、マルチキャストではなくユニキャスト経由でクエリを実行することも可能です。
Because an NBP replacement needs to operate in a Zeroconf environment, it cannot be assumed that a central network administrator is managing the network. Unlike managed networks where normal administrative controls may apply, in the Zeroconf case an NBP replacement must make it easy for users to name their devices as they wish, without the inconvenience or expense of having to seek permission or pay some organization like a domain name registry for the privilege. However, this ease of naming, and freedom to choose any desired name, may lead to name conflicts. Two users may independently decide to run a personal file server on their laptop computers, and (unimaginatively) name it "My Computer". When these two users later attend the next IETF meeting and find themselves part of the same wireless network, there may be problems.
NBPの代替品はZeroconf環境で動作する必要があるため、中央のネットワーク管理者がネットワークを管理しているとは想定できません。通常の管理制御が適用される可能性のある管理対象ネットワークとは異なり、Zeroconfの場合、NBPの交換により、ユーザーが必要に応じて簡単にデバイスに名前を付けられるようにする必要があります。特権のため。ただし、この命名の容易さ、および任意の名前を自由に選択できるため、名前の競合が発生する可能性があります。 2人のユーザーが個別にラップトップコンピュータで個人用ファイルサーバーを実行し、（想像を超えて）「マイコンピュータ」という名前を付ける場合があります。これらの2人のユーザーが後で次のIETFミーティングに参加し、同じワイヤレスネットワークに参加している場合、問題が発生する可能性があります。
Similarly, every Brother network printer may ship from the factory with its Service Name set to "Brother Printer". On a typical small home network where there is only one printer, this is not a problem; however, it could become a problem if two or more such printers are connected to the same network.
同様に、すべてのブラザーネットワークプリンターは、サービス名が「Brother Printer」に設定された状態で工場から出荷される場合があります。プリンターが1つしかない一般的な小規模ホームネットワークでは、これは問題ではありません。ただし、そのようなプリンタが2つ以上同じネットワークに接続されている場合は、問題になる可能性があります。
Any NBP replacement needs to detect such conflicts, and handle them appropriately. In the case of a laptop computer, which has a keyboard, screen, and a human user, the software should display a message telling the user that they need to select a new name.
NBPの交換では、このような競合を検出して適切に処理する必要があります。キーボード、画面、および人間のユーザーがいるラップトップコンピュータの場合、ソフトウェアは、新しい名前を選択する必要があることをユーザーに通知するメッセージを表示する必要があります。
In the case of printers, which typically have no keyboard or screen, the software should automatically select a new unique name, perhaps by appending an integer to the end of the existing name, e.g., "Brother Printer 2". Note that, although this programmatically derived name should be recorded persistently for use next time the device is powered on, the user is not forced to use that name as the long-term name for the service/device. In a network with more than one printer, the typical user will assign human-meaningful names to those printers, such as "Upstairs Printer" and "Downstairs Printer", but the ability to rename the printer using some configuration tool (e.g., a web browser) depends on the ability to find the printer and connect to it in the first place. Hence, the programmatically derived unique name serves a vital bootstrapping role, even if its use in that role is temporary.
通常キーボードや画面がないプリンターの場合、ソフトウェアは自動的に新しい一意の名前を選択する必要があります。たとえば、「Brother Printer 2」のように既存の名前の末尾に整数を追加するなどです。このプログラムで派生した名前は、次回デバイスの電源がオンになったときに使用できるように永続的に記録する必要がありますが、ユーザーはその名前をサービス/デバイスの長期的な名前として使用する必要はありません。複数のプリンターが存在するネットワークでは、一般的なユーザーは、「Upstairs Printer」や「Downstairs Printer」などの意味のある名前をこれらのプリンターに割り当てますが、構成ツール（Webなど）を使用してプリンターの名前を変更する機能ブラウザ）は、最初にプリンタを見つけてそれに接続する機能に依存します。したがって、プログラムで生成された一意の名前は、その役割での使用が一時的であっても、重要なブートストラップの役割を果たします。
Because of the potentially transient nature of connectivity on small portable devices that are becoming more and more common (especially when used with wireless networks), this name conflict detection needs to be an ongoing process. It is not sufficient simply to verify uniqueness of names for a few seconds during the boot process and then assume that the names will remain unique indefinitely.
ますます一般的になってきている（特にワイヤレスネットワークで使用される場合）小型ポータブルデバイスの接続の一時的な性質のため、この名前の競合の検出は継続的なプロセスである必要があります。起動プロセス中に数秒間名前の一意性を確認し、名前が無期限に一意であると想定するだけでは十分ではありません。
If the Zeroconf naming mechanism is integrated with the existing global DNS naming mechanism, then it would be beneficial for a sub-tree of that global namespace to be designated as having only local significance, for use without charge by cooperating peers, much as portions of the IPv4 address space are already designated as local-significance-only, available for organizations to use locally without charge as they wish [RFC1918].
Zeroconf命名メカニズムが既存のグローバルDNS命名メカニズムと統合されている場合、そのグローバルネームスペースのサブツリーがローカルの重要性のみを持つものとして指定され、協調するピアによる課金なしで使用するために、 IPv4アドレススペースは既にローカルシグニフィカンスのみとして指定されており、組織が希望どおりに無料でローカルで使用できる[RFC1918]
When the user selects their default printer, the software should store only the name, not the IP address and port number. Then, every time the user prints, the software should look up the name to find the current IP address and port number for that service. This allows a named logical service to be moved from one piece of hardware to another without disrupting the user's ability to print to that named print service.
ユーザーがデフォルトのプリンターを選択すると、ソフトウェアは名前のみを保存し、IPアドレスとポート番号は保存しません。その後、ユーザーが印刷するたびに、ソフトウェアは名前を検索して、そのサービスの現在のIPアドレスとポート番号を見つける必要があります。これにより、ユーザーがその名前付き印刷サービスに印刷する機能を妨げることなく、名前付き論理サービスをハードウェアの一部から別のハードウェアに移動できます。
On a network using DHCP [RFC2131] or self-assigned link-local addresses [RFC3927] [RFC4862], a device's IP address may change from day to day. Deferring binding of name to address until actual use allows the client to get the correct IP address at the time the service is used.
DHCP [RFC2131]または自己割り当てのリンクローカルアドレス[RFC3927] [RFC4862]を使用するネットワークでは、デバイスのIPアドレスが日々変化する場合があります。名前のアドレスへのバインディングを実際の使用まで延期すると、クライアントはサービスの使用時に正しいIPアドレスを取得できます。
Similarly, with a service using a dynamic port number instead of a fixed well-known port, the service may not get the same port number every time it is started or restarted. By deferring binding of name to port number until actual use, the client gets the correct port number at the time the service is used.
同様に、既知の固定ポートの代わりに動的ポート番号を使用するサービスでは、サービスが開始または再起動されるたびに同じポート番号を取得しない場合があります。名前のポート番号へのバインディングを実際に使用するまで延期することにより、クライアントはサービスの使用時に正しいポート番号を取得します。
Any NBP replacement needs to be simple enough that vendors of even a low-cost network ink-jet printer can afford to implement it in the device's limited firmware.
すべてのNBPの交換は、低コストのネットワークインクジェットプリンターのベンダーでさえ、デバイスの限られたファームウェアに実装する余裕があるほど単純である必要があります。
AppleTalk NBP offers certain limited wild-card functionality. For example, the service name "=" means "any name". This allows a client to perform an NBP lookup such as "=:LaserWriter@My Zone" and receive back in response a list of all the PS/PAP (AppleTalk Printer Access Protocol) printers in the Zone called "My Zone".
AppleTalk NBPは、特定の限定されたワイルドカード機能を提供します。たとえば、サービス名「=」は「任意の名前」を意味します。これにより、クライアントは「=：LaserWriter @ My Zone」などのNBPルックアップを実行し、「My Zone」と呼ばれるゾーン内のすべてのPS / PAP（AppleTalkプリンターアクセスプロトコル）プリンターのリストの応答を受け取ることができます。
Any NBP replacement needs to allow a piece of software, such as a printing client or a file server client, to enumerate all the named instances of services in a specified zone (domain) that speak its protocol(s).
NBPを置き換える場合は、印刷クライアントやファイルサーバークライアントなどのソフトウェアが、指定されたゾーン（ドメイン）で、そのプロトコルを話すサービスの名前付きインスタンスをすべて列挙できるようにする必要があります。
AppleTalk NBP provides certain meta-information to the client.
AppleTalk NBPは、特定のメタ情報をクライアントに提供します。
On a network with multiple AppleTalk Zones, the AppleTalk network infrastructure informs the client of the list of Zones that are available for browsing. It also informs the client of the default Zone, which defines the client's logical "home" location. This is the Zone that is selected by default when the Macintosh Chooser is opened, and is usually the Zone where the user is most likely to find services like printers that are physically nearby, but the user is still free to browse any Zone in the offered list that they wish.
AppleTalkゾーンが複数あるネットワークでは、AppleTalkネットワークインフラストラクチャが、クライアントに、参照可能なゾーンのリストを通知します。また、クライアントに、クライアントの論理的な「ホーム」ロケーションを定義するデフォルトゾーンを通知します。これは、Macintoshセレクターを開いたときにデフォルトで選択されるゾーンであり、通常、ユーザーが物理的に近くにあるプリンターなどのサービスを見つける可能性が最も高いゾーンですが、ユーザーは提供されたゾーンを自由に参照できます。彼らが望むリスト。
A Brother printer may be pre-configured at the factory with the Service Name "Brother Printer", but they do not know on which network the printer will eventually be installed, so the printer will have to learn this from the network on arrival. On a network with multiple AppleTalk Zones, the AppleTalk network infrastructure informs the client of a single default Zone within which it may register Service Names. In the case of a device with a human user, the AppleTalk network infrastructure may also inform the client of a list of Zones within which the client may register Service Names, and the user may choose to register Service Names in any one of those Zones instead of in the suggested default Zone.
ブラザープリンターは「ブラザープリンター」というサービス名で工場で事前設定されている場合がありますが、最終的にプリンターがインストールされるネットワークがわからないため、プリンターは到着時にネットワークからこれを学習する必要があります。複数のAppleTalkゾーンがあるネットワークでは、AppleTalkネットワークインフラストラクチャは、サービス名を登録できる単一のデフォルトゾーンをクライアントに通知します。人間のユーザーがいるデバイスの場合、AppleTalkネットワークインフラストラクチャは、クライアントにサービス名を登録できるゾーンのリストをクライアントに通知することもでき、ユーザーは代わりにそれらのゾーンのいずれかにサービス名を登録することを選択できます提案されたデフォルトのゾーンでの。
Any NBP replacement needs to provide the following information to the client:
NBPの交換では、次の情報をクライアントに提供する必要があります。
* The suggested zone (domain) in which to register Service Names.
* サービス名を登録するための推奨ゾーン（ドメイン）。
* A list of recommended available zones (domains) in which Service Names may be optionally registered.
* サービス名をオプションで登録できる推奨利用可能ゾーン（ドメイン）のリスト。
* The suggested default zone (domain) for network browsing.
* ネットワークブラウジング用に推奨されるデフォルトゾーン（ドメイン）。
* A list of available zones (domains) that may be browsed.
* 参照できる利用可能なゾーン（ドメイン）のリスト。
Note that, because the domains used in this context are intended for service browsing in a graphical user interface, they should be permitted to be full user-friendly rich text, just like the rest of a service name.
このコンテキストで使用されるドメインは、グラフィカルユーザーインターフェイスでのサービスの閲覧を目的としているため、他のサービス名と同様に、完全なユーザーフレンドリーなリッチテキストである必要があります。
Many modern network devices have the ability to go into a low-power mode, where only a small part of the Ethernet hardware remains powered, and the device can be woken up by sending a specially formatted Ethernet frame that the device's power-management hardware recognizes. A modern service discovery protocol should provide facilities to enable this low-power mode to be used effectively without sacrificing network functionality, such as the ability to discover services on sleeping devices, and wake up a sleeping device when it is needed.
最新のネットワークデバイスの多くは、イーサネットハードウェアのごく一部のみに電力が供給されている低電力モードに入ることができ、デバイスの電源管理ハードウェアが認識する特別にフォーマットされたイーサネットフレームを送信することにより、デバイスをウェイクアップできます。最新のサービス検出プロトコルは、ネットワーク機能を犠牲にすることなく、この低電力モードを効果的に使用できる機能を提供する必要があります。たとえば、スリープ状態のデバイスでサービスを発見し、必要なときにスリープ状態のデバイスをウェイクアップできます。
Fashions come and go in the computer industry, but a service discovery protocol, being one of the foundation components on which everything else rests, has to be able to outlive these swings of fashion. A useful service discovery protocol should be agnostic to the protocols being used by the higher-layer software it serves. If a service discovery protocol requires all the higher-layer software to be written in a new computer language, or requires all the higher-layer protocols to embrace some trendy new data representation format that is currently in vogue, then that service discovery protocol is likely to have limited utility after the fashion changes and computer industry moves on to its next infatuation.
ファッションはコンピュータ業界で出入りしますが、サービスディスカバリプロトコルは、他のすべてが依存する基盤コンポーネントの1つであるため、これらのファッションの変化に耐えることができなければなりません。有用なサービス検出プロトコルは、サービスを提供する上位層のソフトウェアが使用しているプロトコルにとらわれない必要があります。サービス検出プロトコルですべての上位層ソフトウェアを新しいコンピューター言語で作成する必要がある場合、またはすべての上位層プロトコルで現在流行している流行の新しいデータ表現形式を採用する必要がある場合、そのサービス検出プロトコルはおそらくファッションの変化とコンピュータ業界の次の夢中になった後のユーティリティの制限。
Any modern service discovery protocol must use some kind of caching for efficiency. Any time a distributed cache is maintained, a cache coherency protocol is required to control the effects of stale data. Thus, a useful service discovery protocol needs to include cache coherency mechanisms.
最新のサービスディスカバリプロトコルは、効率を上げるために何らかのキャッシュを使用する必要があります。分散キャッシュが維持される場合は常に、古いデータの影響を制御するためにキャッシュコヒーレンシプロトコルが必要です。したがって、有用なサービス検出プロトコルには、キャッシュコヒーレンシメカニズムを含める必要があります。
Many current discovery mechanisms display an hourglass or a "Please Wait" message for five or ten seconds, and then present a list of results to the user. At this point, the list of results is static, and does not update in response to changes in the environment. To see current information, the user is forced to click a "Refresh" button repeatedly, waiting another five to ten seconds each time.
現在の多くの検出メカニズムでは、砂時計または「しばらくお待ちください」メッセージが5〜10秒間表示され、結果のリストがユーザーに表示されます。この時点では、結果のリストは静的であり、環境の変化に応じて更新されません。現在の情報を表示するには、ユーザーは[更新]ボタンを繰り返しクリックする必要があり、毎回さらに5〜10秒待機します。
Neither limitation is acceptable in a protocol that is to replace NBP. When a user initiates a browsing operation, the user interface should take at most one second to present the list of results. In addition, the list should update in response to changes in the environment as they happen. If the user is waiting for a particular service to become available, they should be able simply to watch until it appears, with no "Refresh" button that they need to keep clicking. A protocol to replace AppleTalk NBP must be able to meet these requirement for timeliness of information discovery, and liveness of information updating, without placing undue burden on the network.
NBPを置き換えるプロトコルでは、どちらの制限も受け入れられません。ユーザーがブラウジング操作を開始すると、ユーザーインターフェイスは結果のリストを表示するのに最大で1秒かかるはずです。また、リストは環境の変化に応じて更新されます。ユーザーが特定のサービスが利用可能になるのを待っている場合、ユーザーはクリックする必要のある[更新]ボタンがなくても、それが表示されるまで簡単に監視できるはずです。 AppleTalk NBPに取って代わるプロトコルは、ネットワークに過度の負担をかけることなく、情報発見の適時性、および情報更新の活性に対するこれらの要件を満たす必要があります。
Ever since this work began with Stuart Cheshire's email to the net-thinkers@thumper.vmeng.com mailing list in July 1997, the question has been asked, "Isn't SLP the IETF replacement for AppleTalk NBP?"
この作業が1997年7月のnet-thinkers@thumper.vmeng.comメーリングリストへのスチュアートチェシャーのメールで始まって以来、「SLPはAppleTalk NBPのIETFの代替品ではないのですか？」
The Service Location Protocol (SLP) [RFC2608] provides extremely rich and flexible facilities in the area of Requirement 10, "Network Browsing". However, SLP provides none of the service naming, automatic name conflict detection, or efficient name-to-address lookup that form the majority of what AppleTalk NBP does.
Service Location Protocol（SLP）[RFC2608]は、要件10「ネットワークブラウジング」の分野で非常に豊富で柔軟な機能を提供します。ただし、SLPは、AppleTalk NBPが行うことの大部分を形成するサービスの名前付け、自動名前競合検出、または効率的な名前からアドレスの検索を提供しません。
SLP returns results in the form of URLs. In the absence of DNS, URLs cannot usefully contain DNS names. Discovering a list of service URLs of the form "ipp://169.254.17.202/" is not particularly informative to the user. Discovering a list of service URLs of the form "ipp://epson-stylus-900n.local./" is slightly less opaque (though still not very user-friendly), but to do even this, SLP would have to depend on Multicast DNS or something similar to resolve names to addresses in the absence of a conventional DNS server.
SLPは結果をURLの形式で返します。 DNSがない場合、URLにDNS名を含めることはできません。 「ipp：//169.254.17.202/」という形式のサービスURLのリストを見つけることは、ユーザーにとって特に有益ではありません。 「ipp：//epson-stylus-900n.local./」という形式のサービスURLのリストを見つけることは、少し不透明ではありません（ただし、ユーザーフレンドリーではありません）が、これを行うには、SLPが依存する必要があります。マルチキャストDNS、または従来のDNSサーバーがない場合に名前をアドレスに解決するための類似のもの。
SLP provides fine-grained query capabilities, such as the ability to prune a long list of printers to show only those that have blue paper in the top tray, which could be useful on extremely large networks with very many printers, but are certainly unnecessary for a typical home or small office with only one or two printers.
SLPは、きめ細かなクエリ機能を提供します。たとえば、プリンターの長いリストをプルーニングして、上部トレイに青い紙があるプリンターのみを表示する機能は、非常に多くのプリンターがある非常に大規模なネットワークでは有用ですが、 1つまたは2つのプリンターのみを備えた一般的な家庭または小規模オフィス。
In summary, SLP alone fails to meet most of the requirements, and provides vastly more mechanism than necessary in the area of Requirement 10.
要約すると、SLPだけではほとんどの要件を満たせず、要件10の領域で必要なメカニズムよりもはるかに多くのメカニズムを提供します。
An IP replacement for the AppleTalk Name Binding Protocol needs to support IPv6 as well as IPv4.
AppleTalk Name Binding ProtocolのIP置換は、IPv4だけでなくIPv6もサポートする必要があります。
The AppleTalk Name Binding Protocol was developed in an era when little consideration was given to security issues. In today's world, this would no longer be appropriate. Any modern replacement for AppleTalk NBP should have security measures appropriate to the environment in which it will be used. Given that this document is a broad historical overview of how AppleTalk NBP worked, and does not specify any new protocol(s), it is beyond the scope of this document to provide detailed discussion of possible network environments, what protocols would be appropriate in each, and what security measures would be expected of each such protocol.
AppleTalk Name Binding Protocolは、セキュリティの問題がほとんど考慮されていない時代に開発されました。今日の世界では、これはもはや適切ではありません。 AppleTalk NBPの最新の代替品には、それが使用される環境に適したセキュリティ対策が必要です。このドキュメントは、AppleTalk NBPがどのように機能したかについての広範な歴史的概要であり、新しいプロトコルを指定していないため、考えられるネットワーク環境、それぞれに適切なプロトコルについて詳しく説明することは、このドキュメントの範囲を超えています。 、およびそのような各プロトコルにどのようなセキュリティ対策が期待されるか。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、1997年3月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608] Guttman、E.、Perkins、C.、Veizades、J。、およびM. Day、「Service Location Protocol、バージョン2」、RFC 2608、1999年6月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927] Cheshire、S.、Aboba、B。、およびE. Guttman、「Dynamic Configuration of IPv4 Link-Local Addresses」、RFC 3927、2005年5月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013.
[RFC6762] Cheshire、S。およびM. Krochmal、「マルチキャストDNS」、RFC 6762、2013年2月。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNSベースのサービスディスカバリ」、RFC 6763、2013年2月。
Authors' Addresses
著者のアドレス
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino、CA 95014 USA
Phone: +1 408 974 3207
EMail: cheshire@apple.com
Marc Krochmal Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Marc Krochmal Apple Inc. 1 Infinite Loop Cupertino、CA 95014 USA
Phone: +1 408 974 4368
EMail: marc@apple.com