One document matched: draft-cheshire-dnsext-nbp-03.txt
Differences from draft-cheshire-dnsext-nbp-02.txt
Document: draft-cheshire-dnsext-nbp-03.txt Stuart Cheshire
Category: Informational Apple Computer, Inc.
Expires 14th August 2004 Marc Krochmal
Apple Computer, Inc.
14th February 2004
Requirements for a Protocol to Replace AppleTalk NBP
<draft-cheshire-dnsext-nbp-03.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may
also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Distribution of this memo is unlimited.
Abstract
One of the implicitly understood goals amongst the participants
working on "Multicast DNS", "Link-Local Multicast Name Resolution",
"Zeroconf Name Service", "Rendezvous" (or whatever you like to call
it) is the ability to retire AppleTalk Name Binding Protocol, NetBIOS
naming, and the like, and replace them with an all-IP solution. This
document outlines the specific properties required of an IP
replacement for AppleTalk Name Binding Protocol.
Expires 14th August 2004 Cheshire [Page 1]
Internet Draft Replacement of AppleTalk NBP 14th February 2004
Table of Contents
1. Introduction.....................................................3
2. Requirements.....................................................4
2.1 Name-to-Address Mapping.........................................4
2.2 Name Services, not Hardware.....................................4
2.3 Address Services, not Hardware..................................5
2.4 Typed Name Space................................................7
2.5 User-Friendly Names.............................................8
2.6 Zeroconf Operation..............................................8
2.7 Name Space Management...........................................8
2.8 Late Binding...................................................10
2.9 Simplicity.....................................................10
2.10 Network Browsing..............................................10
2.11 Browsing and Registration Guidance............................11
2.12 Power Management Support......................................11
2.13 Protocol Agnostic.............................................12
2.14 Distributed Cache Coherency Protocol..........................12
2.15 Immediate and Ongoing Information Presentation................12
3. Existing Protocols..............................................13
4. IPv6 Considerations.............................................14
5. Security Considerations.........................................14
6. IANA Considerations.............................................14
7. Copyright.......................................................15
8. References......................................................15
9. Author's Address................................................16
Expires 14th August 2004 Cheshire [Page 2]
Internet Draft Replacement of AppleTalk NBP 14th February 2004
1. Introduction
A common goal of many of the parties working on Multicast DNS
[mDNS] [LLMNR] is to provide a viable IP-based replacement for
AppleTalk Name Binding Protocol (NBP). The precise requirements of
such an IP-based replacement have been assumed but not written down.
Furthermore, it is likely that each person has a different idea of
what the unstated assumptions are, leading to miscommunication and
misunderstandings when discussing what Multicast DNS should do and
how it should work. Finally, there are many who are experts in the
area of DNS who know nothing about NBP, and without any knowledge of
the hitherto unstated goal, it is difficult to understand the
reasoning and motivations that led to some of the design decisions.
This document seeks to remedy this problem by clearly stating the
requirements for an IP-based replacement for NBP. Replacing NBP is
not the sole goal of Multicast DNS, and therefore these requirements
are not the sole design considerations. However, replacing NBP is a
major motivation behind the work in Multicast DNS. A Multicast DNS
solution that is, amongst other things, a viable replacement for NBP,
is much more compelling than one which is not.
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. 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, probably in the
form of UTF-8. AppleTalk NBP has no built-in security provisions; an
IP-based replacement cannot have that same error. AppleTalk NBP has a
reputation, partially deserved, partially not, 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.
The proposals described in "Multicast DNS" [mDNS] and "DNS-Based
Service Discovery" [DNS-SD], taken together, describe a solution that
meets these requirements. This document is written, in part, in
response to a request for more background information to support why
those proposals are necessary.
Expires 14th August 2004 Cheshire [Page 3]
Internet Draft Replacement of AppleTalk NBP 14th February 2004
2. Requirements
This Section lists the 14 requirements for an IP-based replacement
for AppleTalk NBP.
2.1 Name-to-Address Mapping
NBP's primary function is translating names to addresses.
NBP stands for Name Binding Protocol, not Network Browsing Protocol.
Many people know NBP only as "that thing that lets you browse the
network in the Macintosh Chooser". While browsing is an important
facility of NBP, it is secondary to NBP's primary function of
translating names to addresses.
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 then after that, every single time they
print anything, it is a simple efficient name-to-address lookup that
is being performed, not a full-fledged browsing operation.
Any NBP replacement needs to support, as it's primary function,
an efficient name-to-address lookup operation.
2.2 Name Services, not Hardware
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.
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 which 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.
Consequently, this means that the only thing worth naming is 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
Expires 14th August 2004 Cheshire [Page 4]
Internet Draft Replacement of AppleTalk NBP 14th February 2004
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.
2.3 Address Services, not Hardware
-or-
Escape the Tyranny of Well Known Ports
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
each of those names refer to a different host. They are clearly
intended to be logical service names, and could in fact all refer to
the same IP address.
The shortcoming here is that although the names are clearly logical
service names, the result today of doing a conventional ("A" Record)
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 TCP or UDP port number at
which the service can be reached, not just the IP address.
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.
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 independent
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 port number (socket number) within that
host. In contrast, if an lpr print server offers three print queues,
Expires 14th August 2004 Cheshire [Page 5]
Internet Draft Replacement of AppleTalk NBP 14th February 2004
all three print queues are typically reached through the same
well-known port number, 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 use
the same well-known port.
A similar trick is used in HTTP 1.1, where the "Host" header 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 you
have an image server, a database program, an http email access
gateway, and a regular http server, they can't all run on the same
TCP port on the same machine.
Yet another problem of well-known ports is that port numbers are a
finite resource. Originally, port numbers 0-1023 were reserved for
well-known services, and the remaining 98% of the port space was free
for dynamic allocation. 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.
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.
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.
Expires 14th August 2004 Cheshire [Page 6]
Internet Draft Replacement of AppleTalk NBP 14th February 2004
2.4 Typed Name Space
AppleTalk NBP names are structured names, generally written as:
Name : Type @ Zone
Name: The Name is the user-visible name of the service.
Type: The Type is an opaque identifier which 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 PostScript over PAP/ATP/DDP (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 recordable
CDs 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; e.g. 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.
Zone: The Zone is an organizational or geographical grouping of named
services. Typical AppleTalk Zone Names are things like "Engineering"
and "Sales". The equivalent concept in DNS could be a subdomain such
as "engineering.company.com." or "sales.company.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".
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.
Expires 14th August 2004 Cheshire [Page 7]
Internet Draft Replacement of AppleTalk NBP 14th February 2004
2.5 User-Friendly Names
When repeatedly typing in names on command-line systems, it is
helpful to have names that are short, all lower-case, with no spaces
or other unusual 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.ietf.org." Of course a user is free to restrict their
Service Names to lower-case letters without spaces if they wish, but
they should not be forced to do that.
Any NBP replacement needs to support a full range of rich text
characters, including upper case, lower case, spaces, accented
characters, and so on. The correct solution is likely to be Unicode,
probably in the form of UTF-8.
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 use of any desired
characters in service names, including dots ('.'), spaces, percent
signs, etc.
2.6 Zeroconf Operation
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.
Any NBP replacement needs to operate in the absence of external
network infrastructure. It should also be able to take advantage of
appropriate external network infrastructure, where present, to
perform queries via unicast instead of multicast.
2.7 Name Space Management
-or-
Name Conflict Detection
Because an NBP replacement needs to operate in a Zeroconf
environment, it cannot be assumed that a central network
administrator is managing the network. In a managed network
Expires 14th August 2004 Cheshire [Page 8]
Internet Draft Replacement of AppleTalk NBP 14th February 2004
normal administrative controls may apply, but 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 means that 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.
Similarly, every Brother Ethernet 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,
but it could be a problem if two or more such printers are connected
to the same network.
Any NBP replacement needs to detect such conflicts, and handle them
appropriately. In the case of the laptop computers, which have
keyboards, screens, and human users, the software should display a
message telling one or both users that they need to select a new
name.
In the case of the printers which 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 this programmatically-derived name would
normally not be used as the long-term persistent 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
short-lived.
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 to simply 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 [RFC 1918].
Expires 14th August 2004 Cheshire [Page 9]
Internet Draft Replacement of AppleTalk NBP 14th February 2004
2.8 Late Binding
When the user selects their default printer, the software should not
store the IP address and port number, but just the name. 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.
On a network using DHCP or self-assigned link-local addresses, a
device's IP address may change from day to day. By deferring binding
of name to address until actual use, this allows the client to get
the correct IP address at the time the service is used.
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, this allows the client to get the
correct port number at the time the service is used.
2.9 Simplicity
Any NBP replacement needs to be simple enough that vendors of even
the cheapest ink-jet printer can afford to implement it in the
device's limited firmware.
2.10 Network Browsing
AppleTalk NBP offers certain limited wildcard functionality. For
example, the service name "=" means "any name". This allows a client
to perform an NBP lookup such as "=:LaserWriter@MyZone" and receive
back in response a list of all the PAP (AppleTalk Printer Access
Protocol) printers in the Zone called "MyZone".
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) which speak its
protocol(s).
Expires 14th August 2004 Cheshire [Page 10]
Internet Draft Replacement of AppleTalk NBP 14th February 2004
2.11 Browsing and Registration Guidance
AppleTalk NBP provides certain meta-information to the client.
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.
A Brother printer may be preconfigured 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.
Any NBP replacement needs to provide the following information to
the client:
* 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) which may be browsed.
2.12 Power Management Support
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 which 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
wake a device up when it is needed.
Expires 14th August 2004 Cheshire [Page 11]
Internet Draft Replacement of AppleTalk NBP 14th February 2004
2.13 Protocol Agnostic
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 protocols 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.
2.14 Distributed Cache Coherency Protocol
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.
2.15 Immediate and Ongoing Information Presentation
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.
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.
Expires 14th August 2004 Cheshire [Page 12]
Internet Draft Replacement of AppleTalk NBP 14th February 2004
3. Existing Protocols
The question has been asked, "Isn't SLP the IETF replacement for
NBP?"
SLP [RFC 2608] 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 which form the majority of what
AppleTalk NBP does.
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 some other not-yet-standardized local
multicast naming protocol to resolve names to addresses in the
absence of a conventional DNS server.
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.
In summary, SLP alone fails to meet most of the requirements,
and provides vastly more mechanism than necessary in the area of
Requirement 10.
Expires 14th August 2004 Cheshire [Page 13]
Internet Draft Replacement of AppleTalk NBP 14th February 2004
4. IPv6 Considerations
An IP replacement for AppleTalk Name Binding Protocol needs to
support IPv6 addresses as well as it supports IPv4 addresses.
5. Security Considerations
AppleTalk Name Binding Protocol has no inherent security mechanism.
This would not be acceptable in an IP replacement. It should be
possible for a client to verify the authenticity of the information
it is receiving. It may also be useful for a server to be able to
verify that a client has authority to request that information, and
it may be useful to have a way to encrypt the data in transit to
protect it against eavesdropping.
A solution based on or derived from DNS could use DNSSEC [RFC 2535]
to meet these requirements. A solution using some entirely new
protocol would have to invent all of its own mechanisms and policies
for security. (The reader is reminded that this is a requirements
document. Its purpose is to specify requirements, not solutions.
Hence, discussion of specific solutions is not appropriate here.)
6. IANA Considerations
AppleTalk Name Binding Protocol defines a name space for Zones, a
name space for service Types, and name spaces for named instances of
those services. Each name space uses 32-character ASCII text strings,
so the name space for Type names is sufficiently large and
sufficiently sparsely used that Apple never bothered with maintaining
an official registry of assigned NBP service Type names.
In an IP replacement, the name space of zones (domains) would be
managed the same way as domains are currently managed, which is to
say through delegation from the DNS root. In addition, if Multicast
DNS is successful [mDNS] there will also be a specially reserved
domain available for local use without the overhead of formal
delegation.
IANA should probably manage the name space of service type names, to
prevent unintended name collisions. However, the name space of
textual names is large enough that type names would not be a precious
resource, so they could be handed out freely to anyone who needs one,
effectively without limit.
The name space of instance names is managed locally at each site.
Expires 14th August 2004 Cheshire [Page 14]
Internet Draft Replacement of AppleTalk NBP 14th February 2004
7. Copyright
Copyright (C) The Internet Society 2004.
All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
8. References
[DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service
Discovery", Internet-Draft (work in progress),
draft-cheshire-dnsext-dns-sd-02.txt, February 2004.
[LLMNR] Esibov, Aboba & Thaler, "Linklocal Multicast Name
Resolution (LLMNR)", Internet-Draft (work in progress),
draft-ietf-dnsext-mdns-29.txt, January 2004.
[mDNS] Cheshire, S., and M. Krochmal, "Multicast DNS",
Internet-Draft (work in progress),
draft-cheshire-dnsext-multicastdns-04.txt, February 2004.
[RFC 1918] Rekhter, Y., et al., "Address Allocation for Private
Internets", RFC 1918, February 1996.
[RFC 2535] Eastlake, D. "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC 2608] Guttman, Perkins, Veizades & Day, "Service Location
Protocol, Version 2", RFC 2608, June 1999.
Expires 14th August 2004 Cheshire [Page 15]
Internet Draft Replacement of AppleTalk NBP 14th February 2004
9. Author's Address
Stuart Cheshire
Apple Computer, Inc.
1 Infinite Loop
Cupertino
California 95014
USA
Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org
Marc Krochmal
Apple Computer, Inc.
1 Infinite Loop
Cupertino
California 95014
USA
Phone: +1 408 974 4368
EMail: marc@apple.com
Expires 14th August 2004 Cheshire [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-22 09:12:41 |