Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 6760 M. Krochmal
Category: Informational Apple Inc.
ISSN: 2070-1721 February 2013
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名称绑定协议（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）的作者的目标之一是停用AppleTalk和AppleTalk名称绑定协议（NBP），并用基于IP的解决方案取代它们。本文档简要概述了AppleTalk NBP的功能，并概述了基于IP的替换所需的属性。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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名称绑定协议（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.
许多域名系统（DNS）专家对AppleTalk名称绑定协议（NBP）一无所知。如果没有关于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.
本文件旨在通过明确说明基于IP的AppleTalk和NBP替代品的要求来解决此问题。取代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扩展ASCII作为其字符集。很明显，今天设计的基于IP的替换应该使用Unicode，即UTF-8[RFC3629]的形式。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的一个特点是，它可以在不依赖手动配置或网络服务的情况下运行，以提供自动配置。AppleTalk网络可以小到只有两台通过以太网电缆（或无线）连接的笔记本电脑。
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.
在任何给定网络上，零配置网络协议不一定总是同时用于所有三个领域（寻址、命名和服务发现）。例如，即使在使用DHCP服务器提供地址配置的网络上，用户也可能使用零配置协议进行名称到地址转换和服务发现。事实上，在单个网络上，用户可以使用传统的单播DNS查找Internet网站的地址，同时使用多播DNS查找本地链路上对等方的地址。因此，当在同一网络上一起使用时，零配置网络协议必须与传统配置的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.
本节列出了基于IP的AppleTalk NBP替换的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的浏览功能一次，但在这之后，每次打印内容时，执行的是简单有效的名称地址查找，而不是全面的浏览操作。
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.
因此，这意味着唯一值得命名的东西是可以与之通信的软件实体。想要使用打印服务器或文件服务器的用户不必关心是什么硬件实现了这些服务。可能有一台机器同时托管这两项服务，也可能有两台独立的机器。最终用户不需要关心。
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.
唯一的例外是网络管理员，他们可能希望命名物理硬件以跟踪物理资源清册。然而，即使这样，也可以通过说您所命名的不是硬件，而是在每个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.
这意味着端口号必须以其他方式进行带外通信。一种方法是将端口号作为任何给定协议的特定已知常量。这使得在单个硬件上运行多个服务实例变得困难。另一种方法是用户显式键入端口号，例如，“www.example.com.：8080”而不是“www.example.com.”，但需要知道并键入端口号与需要知道并键入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
在单个硬件上运行多个服务实例的另一个困难是，它迫使应用程序程序员编写自己的解复用功能。AppleTalk没有受到这种限制。如果AppleTalk打印服务器提供三个打印队列，则每个打印队列作为其自己的独立服务运行，侦听其自己的端口号（在AppleTalk术语中称为套接字号），每个打印队列作为单独的、独立命名的NBP实体发布。当客户端查找该命名NBP实体的地址时，应答不仅编码服务所在的网络和子网，以及该子网上的主机（就像IP地址一样），还编码该主机内的哪个套接字号（端口号）。相反，如果lpr打印服务器提供三个打印队列，则通常通过相同的已知端口号（515）到达所有三个打印队列，然后lpr协议必须使用自己的端口号
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.
解复用功能（打印队列名称），以确定寻找哪个打印队列。这使得在同一台机器上运行来自不同供应商的两个不同的打印队列软件变得特别困难，因为它们不能同时侦听同一个已知端口。
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服务器），则他们无法全部在TCP端口80（传统HTTP端口）上侦听。
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系统这样的协议明智地使用一系列端口号，并让TCP为它们执行解复用。X Window系统使用64个端口，范围为6000-6063。如果每个新协议都有自己的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.
任何NBP替换都不仅需要提供该子网内的网络号、子网号和主机号（即IP地址），还需要提供服务所在主机内的端口号。此外，由于许多现有的IP服务（如lpr*do*等）已经使用了额外的应用层解复用信息（如打印队列名称），因此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.
这里一个可能的答案是，基于IP的NBP替换可以使用从DNS SRV记录派生的解决方案，而不是“a”记录，因为SRV记录*确实*提供端口号。但是，这并不是一个完整的解决方案，因为SRV记录无法告诉您lpr打印队列名称。
AppleTalk NBP names are structured names, generally written as:
AppleTalk NBP名称是结构化名称，通常写为：
Name : Type @ Zone
名称：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.
类型：类型是标识服务协议和语义的不透明标识符。用户可能认为该类型标识了设备执行的最终用户功能（例如，“打印”），对于典型的最终用户，这可能是一个足够的心智模型，但严格来说，从协议设计的角度来看，该类型标识了服务所说的语义应用协议：不多也不少。为方便起见，不透明类型标识符通常使用描述性ASCII文本构造，但该文本对协议没有任何意义，应注意从中推断太多的意义。例如，NBP服务类型“LaserWriter”意味着“任何讲PS/PAP/ATP/DDP（PostScript over AppleTalk Printer Access Protocol over AppleTalk Transaction Protocol over AppleTalk Datagram Delivery Protocol over AppleTalk Transaction Protocol over AppleTalk Datagram Delivery Protocol）的服务”。这并不一定意味着苹果品牌的“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号楼”。DNS中的等效概念可以是子域，如“Engineering.example.com.”、“Sales.example.com.”或“Building 1，3rd floor，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}对定义一个名称空间，可以在其中注册服务名称。一台名为“Sales”的打印机和一台名为“Sales”的文件服务器并不存在名称冲突，因为其中一台是“Sales:LaserWriter@Zone另一个是“销售：AFPServer@Zone".
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”。当然，如果用户愿意，他们可以自由地使用小写字母命名特定服务，而不使用空格，但不应该强迫他们这样做。
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是自配置的。在只有两台主机的网络上，它们使用多播进行对等通信。在大型受管网络上，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的替换必须使用户能够方便地按照自己的意愿命名设备，而无需为获得特权而寻求许可或向域名注册机构等组织付费，从而带来不便或费用。然而，这种命名的便利性，以及选择所需名称的自由，可能会导致名称冲突。两个用户可能独立决定在他们的笔记本电脑上运行个人文件服务器，并（难以想象地）将其命名为“我的电脑”。当这两个用户稍后参加下一次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网络打印机出厂时，其服务名称可能设置为“Brother printer”。在只有一台打印机的典型小型家庭网络上，这不是问题；但是，如果两个或多个此类打印机连接到同一网络，则可能会出现问题。
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”。请注意，尽管此编程派生的名称应持续记录以供下次设备通电时使用，但用户不会被迫使用该名称作为服务/设备的长期名称。在具有多台打印机的网络中，典型用户会为这些打印机指定有人类意义的名称，例如“楼上打印机”和“楼下打印机”，但使用某些配置工具（例如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提供某些有限的通配符功能。例如，服务名称“=”表示“任何名称”。这允许客户端执行NBP查找，如“=：LaserWriter@My“我的区域”中的所有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 Chooser时默认选择的区域，通常是用户最有可能找到附近的打印机等服务的区域，但用户仍可以自由浏览所提供列表中他们希望的任何区域。
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.
Brother打印机可能在工厂预先配置为服务名称“Brother printer”，但他们不知道打印机最终将安装在哪个网络上，因此打印机必须在到达时从网络了解这一点。在具有多个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.
时尚在计算机行业中来来往往，但服务发现协议是所有其他事物赖以生存的基础组件之一，必须能够超越这些时尚潮流。一个有用的服务发现协议应该与它所服务的高层软件所使用的协议无关。如果服务发现协议要求所有高层软件都使用新的计算机语言编写，或者要求所有高层协议都采用当前流行的某种新数据表示格式，然后，随着时尚的改变和计算机行业进入下一个迷恋期，服务发现协议的实用性可能会受到限制。
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?"
自从这项工作开始于斯图尔特·切希尔的网络电子邮件-thinkers@thumper.vmeng.com在1997年7月的邮件列表中，有人提出这样一个问题：“SLP不是IETF对AppleTalk NBP的替代品吗？”
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.
服务定位协议（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名称。查找表单“”的服务URL列表ipp://169.254.17.202/“对于用户来说，信息量不是特别大。查找表单“”的服务URL列表ipp://epson-stylus-900n.local./“稍微不那么不透明（尽管仍然不是非常用户友好），但要做到这一点，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提供了细粒度的查询功能，例如能够修剪一长串打印机，以便仅显示顶部纸盘中有蓝色纸张的打印机，这在拥有大量打印机的超大网络上可能很有用，但对于只有一台或两台打印机的典型家庭或小型办公室来说，这显然是不必要的。
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名称绑定协议的IP替换需要支持IPv6和IPv4。
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名称绑定协议是在一个很少考虑安全问题的时代开发的。在当今世界，这不再合适。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.，Ed.“互联网主机的要求-通信层”，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.，“动态主机配置协议”，RFC21311997年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，“服务位置协议，版本2”，RFC 26081999年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，“IPv4链路本地地址的动态配置”，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无状态地址自动配置”，RFC 48622007年9月。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013.
[RFC6762]Cheshire，S.和M.Krochmal，“多播DNS”，RFC 67622013年2月。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 67632013年2月。
Authors' Addresses
作者地址
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
斯图尔特柴郡苹果公司，美国加利福尼亚州库比蒂诺市无限环路1号，邮编95014
Phone: +1 408 974 3207
EMail: cheshire@apple.com
Phone: +1 408 974 3207
EMail: cheshire@apple.com
Marc Krochmal Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Marc Krocmal Apple Inc.美国加利福尼亚州库珀蒂诺市无限环路1号，邮编95014
Phone: +1 408 974 4368
EMail: marc@apple.com
Phone: +1 408 974 4368
EMail: marc@apple.com