Internet Engineering Task Force James Kempf
INTERNET DRAFT Sun Microsystems
22 October 1999 Jason Goldschmidt
Bucknell University
Notification and Subscription for SLP
draft-kempf-srvloc-notify-00.txt
Status of This Memo
This document is a submission by the Service Location Working Group
of the Internet Engineering Task Force (IETF). Comments should be
submitted to the srvloc@srvloc.org mailing list.
Distribution of this memo is unlimited.
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.
Abstract
The Service Location Protocol provides mechanisms whereby service
agent clients can advertise and user agent clients can query for
services. The design is very much demand-driven, so that user agents
only obtain service information when they specifically ask for it.
There exists another class of user agent applications, however, that
requires notification when a new service appears or disappears and
update when the attributes of the service change. In the RFC 2608
design, these applications are forced to poll the network to catch
changes. In this document, we describe a protocol for allowing such
Kempf and Goldschmidt Expires 22 March 2000 [Page i]
Internet Draft Notification and Subscription for SLP 22 October 1999
clients to be notified when a change occurs, removing the need for
polling.
Kempf and Goldschmidt Expires 22 March 2000 [Page ii]
Internet Draft Notification and Subscription for SLP 22 October 1999
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Notation Conventions 2
3. Terminology 2
4. Design Considerations 2
5. Notification Design Overview 3
5.1. Small Network Design . . . . . . . . . . . . . . . . . . 4
5.2. Large Network Design . . . . . . . . . . . . . . . . . . 4
6. Subscribe Extension 5
7. NotifyAtExt Extension 6
7.1. NotifyAtExt received with SrvRply . . . . . . . . . . . . 7
7.2. NotifyAtExt received with multicast DAAdvert . . . . . . 7
7.3. NotifyAtExt received with SrvAck . . . . . . . . . . . . 7
8. Multicast Address Allocation 8
9. Multicast Transmit Algorithm 8
10. DA Disappearance 9
11. Network Administration Considerations 9
12. Security Considerations 10
13. Acknowledgements 10
14. Full Copyright Statement 11
Kempf and Goldschmidt Expires 22 March 2000 [Page iii]
Internet Draft Notification and Subscription for SLP 22 October 1999
1. Introduction
The Service Location Protocol (SLP) [1] provides a mechanism for
service agent (SA) clients to advertise network services and for user
agent (UA) clients to find them. The mechanism is demand-driven.
UAs obtain service information by actively querying for it, and do
not obtain any information unless they do so. While this design
satisfies the requirements for most applications, there are some
applications that require more timely information about changes in
the services of interest.
In particular, these applications require notification of the
following events:
1 Appearance of a new advertisement for a particular kind of
service.
2 Disappearance of an advertisement for a particular kind of
service.
3 Change in attributes in the advertisement for a particular kind
of service.
Ideally, these applications would like to be notified when a new
SA comes up, when an SA disappears or when a service advertisement
times out in a DA, and when an SA adds, deletes, or changes the value
of its attributes. In order to obtain this information with SLP
as described in RFC 2608, such applications must poll the network
to periodically refresh their local cache of available service
advertisements.
An example of such a client is a printer that wants to dynamically
advertise a state change in order that administrative applications
can receive up-to-the-minute information about the state of devices
they are administering. Another example is a desktop GUI that wants
to display network service icons as soon as they appear to provide
users with an accurate picture of all services available to them.
Because polling is inefficient and wasteful of network and processor
resources, we would like to provide these applications a mechanism
whereby they can be explicitly notified of changes. In this
document, we describe a scalable mechanism allowing UAs to be
notified of changes in service types of interest.
Kempf and Goldschmidt Expires 22 March 2000 [Page 1]
Internet Draft Notification and Subscription for SLP 22 October 1999
2. Notation Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
3. Terminology
In this section, we present some additional terminology beyond that
in [1] and [2].
Notification
A message sent to an interested agent informing that agent of a
change in state involving another agent.
Subscription
A request to be informed about changes in state for a
particular service type and scopes.
4. Design Considerations
The primary design consideration in a notification protocol for
SLP is that we would like it to exhibit the same high degree of
scalability that the base SLP protocol exhibits. Notification
should work in small networks with only a few SAs, as well as large
enterprise networks with thousands of SAs and hundreds of DAs. Small
networks should not be required to deploy DAs in order to receive the
benefits of notification. We also want to assure that notification
in large networks does not cause heavy processing loads to fall
on any one particular SLP agent. This requires that the task of
notification be distributed rather than centralized, to avoid loading
down one agent with doing all the notification work.
An important consideration is that the UA clients obtain
notifications of SA events in a timely fashion. If a UA has
subscribed to notification for a particular service type, the
UA should receive such notification regardless of the state
of intervening DAs. SLP is transparent with respect to DAs
supporting a particular scope; that is, a UA can use any DA with a
particular scope and expect to get the same service advertisements.
Notifications should exhibit the same property. Whether or not a UA
receives a notification should not depend on the DA to which they
happen to connect. This preserves the DAs' identity as a pure cache.
Kempf and Goldschmidt Expires 22 March 2000 [Page 2]
Internet Draft Notification and Subscription for SLP 22 October 1999
Another consideration, related to the scalability goal, is to
keep the granularity of subscription high enough that notification
messages don't become a burden on the network or the individual
agents. For example, we could design the notification mechanism
such that a notification message is sent for a change on a single
attribute. However, this would cause a flood of notification
messages when an SA changed a few attributes.
A related goal is that the notification messages contain enough
information about the triggering event that the UA can determine
whether or not it is of interest in the large majority of cases
without having to issue another SLP request a priori. The UA may, of
course, issue an SLP request for related reasons, but it should not
have to issue a request to obtain more information on the event that
triggered the notification in most cases. This reduces the amount of
network traffic related to the event.
In order to simplify implementation, we would like to use similar
mechanisms for notification in large and small networks. The
mechanisms may not be identical, obviously, but we want to avoid
having radically different mechanisms that require completely
separate implementations. Having similar mechanisms reduces the
amount of code in UA and SA clients.
A minor goal is to make use of existing SLP message types and
mechanisms wherever possible. This reduces the amount of code
necessary to implement the notification mechanism, because much code
can be reused between the base SLP and the notification mechanism.
In particular, we expect to make use of the SLP extension mechanism
in certain cases to support subscription.
An explicit nongoal of the design is to support notification
frequencies on on the order of seconds or even a few minutes. We
would like notification to be dynamic but we expect the frequency of
update to be on the order of five minutes or more. Applications that
require notification at higher frequencies should use an application
specific protocol designed for higher frequency notification.
5. Notification Design Overview
In order to support scalability, we split the design into two
parts. A small network design is used when no DAs are present in the
network. A large network design is used in networks with DAs. The
following subsections describe the two designs.
Kempf and Goldschmidt Expires 22 March 2000 [Page 3]
Internet Draft Notification and Subscription for SLP 22 October 1999
5.1. Small Network Design
In networks without DAs, UAs are notified by an SA when the SA
initially appears, if any change occurs in attributes, and when the
SA disappears. In small networks, there is no centralized agent
available to administer subscriptions for newly appearing SAs. This
rules out any kind of subscription design in which a UA subscribes
to notifications for a particular service type in particular scopes
of interest, because a newly appearing SA can't tell whether or
not there are any subscriptions without a centralizing agent to
tell it. As a result, SAs perform notification on every state
change regardless of their scope or service type, if they are
capable of performing notification. This means that a UA receives
notification of all types of changes for all scopes and service
types, and consequently must be prepared to filter out those changes
in which it is not interested (other scopes, other service types, or
advertisements that are not of interest because the attributes don't
match attributes in which the UA is interested).
The design requires SAs to perform notification by IP multicasting
(or broadcasting if multicast is not available) one or several SLP
SrvReg or SrvDereg messages describing their state change using the
multicast transmit algorithm described in Section 9. The multicast
is performed on the SLP multicast address (239.255.255.253, default
TTL 255) and is administratively scoped in the same manner as
SLP [4]. The port number for notifications is not the default SLP
port, because that port is only accessible to privileged users,
but rather the port <*to be assigned by IANA*>. UAs interested in
notification join the multicast group 239.255.255.253 and listen on
port <*to be assigned by IANA*>.
5.2. Large Network Design
In networks with DAs, a DA supporting a particular scope can act as
an intermediary for administering UA subscriptions. A UA interested
in being notified about changes in a particular service type attaches
the Subscribe extension to a SrvRqst message sent to the DA. The DA
obtains multicast group addresses based on the algorithm described
in Section 8 and puts them into a NotifyAtExt extension which it
attaches to the SrvRply. The UA listens on the group addresses in
the reply for notifications.
If no previous subscription was seen having the same scope or scopes,
the DA multicasts DAAdverts using the multicast transmit algorithm
described in Section 9 including the NotifyAtExt extension. This
informs existing SAs that a UA has requested a subscription to events
involving their service type. When new SAs register with the DA,
the NotifyAtExt is included in the SrvAck. If the SAs don't support
Kempf and Goldschmidt Expires 22 March 2000 [Page 4]
Internet Draft Notification and Subscription for SLP 22 October 1999
notification, they simply ignore the extension. The DA itself must
also perform notification, according to the multicast transmit
algorithm, when a service advertisement times out. Time-out of a
service advertisement results in the DA multicasting a SrvDereg for
the deregistered URL.
As in small networks, notification is performed primarily by SAs. If
an SA receives a DAAdvert or SrvAck with a NotifyAtExt extension and
the following conditions are met:
1. The SA supports notification.
2. The SA's service type matches the service type in the
NotifyAtExt.
3. The SA's scopes match one of the scopes of the NotifyAtExt
extension.
4. The NotifyAtExt query query matches one or more of the SA's
advertisements.
then the SA saves the multicast addresses that correspond to the
scopes it supports. The SA MUST perform notification immediately
after the SA has performed the SrvReg or SrvDereg with the DA. An SA
that has not received a NotifyAtExt extension in a message from a
DA or that has received a NotifyAtExt that doesn't match any of its
services MUST NOT perform multicast notification.
6. Subscribe Extension
The Subscribe extension has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type = <TBD> | Extension Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Scope List | Scope List \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Service Type Name | Service Type Name \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The scope list has the same format as in the SLP UA requests [1].
The service type name has the same format as in the SLP SrvRqst.
When a DA receives the Subscribe extension, it determines the
multicast addresses to use based on the algorithm described
Kempf and Goldschmidt Expires 22 March 2000 [Page 5]
Internet Draft Notification and Subscription for SLP 22 October 1999
in Section 8. The multicast addresses are then bundled into a
NotifyAtExt along with the scopes and service type. The query
included in the NotifyAtExt is the logical conjunction of all
queries received from all UAs for the subscribed service type in
the accompanying SrvRqsts. The DA also includes a lifetime in the
NotifyAtExt, informing subscribing UAs and notifying SAs how long
the subscription is active. The lifetime is included to prevent
old subscriptions from hanging around after the UA making the
subscription has exited. The NotifyAtExt is then multicast as part
of a DAAdvert according to the multicast transmission algorithm, and
is included in the SrvRply to the requesting UA.
The DA itself is required to perform notification if a service
advertisement times out. This informs the UA that the service
advertisement is no longer valid.
7. NotifyAtExt Extension
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type = <TBD> | Extension Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subscription Lifetime | Length of Scope/Group List |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope/Group List \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Service Type Name | Service Type Name \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Query | Query \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The service type name is in the same format as in the Subscribe
extension. The scope/group list is a list of scope names and
multicast group addresses, in IPv4 dotted decimal notation. The
following ABNF [5] syntax describes the list:
sglist = sgitem / sgitem "," sglist
sgitem = scope-name ":" ipv4-number
scope-name = ; See RFC 2608 for the format of scope names.
ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)
An example of a scope/group list is:
Kempf and Goldschmidt Expires 22 March 2000 [Page 6]
Internet Draft Notification and Subscription for SLP 22 October 1999
eng:239.255.255.42,corp:239.255.255.43
There are three cases in which an agent may receive a NotifyAtExt
extension: in a SrvRply returned to a UA, in a multicast DAAdvert,
and in a SrvAck returned to an SA. The three subsections below
describe the response in each of these cases.
7.1. NotifyAtExt received with SrvRply
When a UA sends a SrvRqst with a Subscribe extension, the DA responds
with a SrvRply including a NotifyAtExt. The DA MUST NOT unicast
a NotifyAtExt to a UA with any other message and MUST NOT send a
NotifyAtExt unless a SrvRqst with a Subscribe extension was received.
The UA responds by setting up a multicast listener to the group
address included in the extension on the SLP notification port <*to
be assigned by IANA*>. The UA MAY also want to note the expiration
lifetime of the subscription assigned by the DA, and reissue a
subscription before the lifetime expires.
7.2. NotifyAtExt received with multicast DAAdvert
The DA multicasts a NotifyAtExt with a DAAdvert using the multicast
transmit algorithm when a UA has requested notification. This
message informs existing SAs having the service type and scopes in
the announcement that they should multicast notifications upon state
changes if the query matches their attributes.
A receiving SA participating in notification responds by noting the
multicast address if the service type, scopes, and query match.
When a state change (change in attributes, deregistration) occurs,
the SA MUST first inform all its DAs of the change, then it MUST
multicast the same message sent to the DAs according to the multicast
transmit algorithm. The SA MUST cease performing notification when
the lifetime expires, unless a subsequent NotifyAtExt is received
prolonging the subscription.
A UA that is performing passive DA detection will naturally also
receive the extension, but the UA SHOULD ignore the extension.
7.3. NotifyAtExt received with SrvAck
An SA can receive a NotifyAtExt with a SrvAck when if first comes up
and registers itself with a DA. If the DA has any subscriptions from
Kempf and Goldschmidt Expires 22 March 2000 [Page 7]
Internet Draft Notification and Subscription for SLP 22 October 1999
UAs for the service type and scopes represented by the SA, it returns
a NotifyAtExt with the SrvAck.
The SA upon receiving the NotifyAtExt takes exactly the same actions
as when it receives a NotifyAtExt along with a multicast DAAdvert.
Additionally, it MUST immediately perform a multicast notification of
its SrvReg if the scopes, service type, and query of the NotifyAtExt
apply.
8. Multicast Address Allocation
Enterprise networks that allow SLP notification SHOULD deploy
the Multicast Address Allocation Architecture (MAAA) including
administratively scoped multicast and Multicast Address Dynamic
Client Allocation Protocol (MADCAP) [7].
If the MAAA infrastructure is not deployed, the SLP multicast address
is used for notifications.
If the MAAA infrastructure is deployed, the MADCAP servers MUST
be configured with multicast scopes to support SLP scopes. Each
SLP scope MUST correspond to a multicast scope name, in the sense
of [7]. In such a case, a DA obtains the base multicast addresses
and ranges for the SLP scopes it supports using MADCAP. The multicast
group address used for SLP notifications is at the IANA-assigned
fixed offset of 2 below the last multicast address in the scope, as
described for SLP in [6]. This is the same address used for other
SLP multicasting in administratively scoped networks.
9. Multicast Transmit Algorithm
The DA and SAs use a multicast transmit algorithm similar to that
used for discovering services in SLP, described in RFC 2608 [1],
except the agent performing the notification doesn't wait for
replies. The agent performing the notification transmits a
notification message periodically over an interval of 15 seconds.
The number of retransmits should vary according to network
congestion, but a minimum of 6 and a maximum of one per second is
recommended.
A notification message is either a SrvReg or a SrvDereg message,
depending on whether the SA is registering a new service or adding
attributes to an existing service, or deregistering a service or
deleting attributes from an existing service. If a new service is
registered, the notification message MUST have the fresh bit set in
the SLP header of the multicast SrvReg message. Since SrvReg and
SrvDereg contain attribute lists of arbitrary length, the message
Kempf and Goldschmidt Expires 22 March 2000 [Page 8]
Internet Draft Notification and Subscription for SLP 22 October 1999
could potentially overflow the packet MTU for UDP. If an attribute
list causes a packet MTU overflow, the transmitting agent MUST set
the overflow bit in the SLP header. The attribute list in the
notification message MUST be formatted so that a UA can use the
attributes even if an overflow occurs. If a UA needs more attributes
than are transmitted in the notification message, it can contact the
SA (if no DA is present) or the DA for the attributes it needs.
A DA also multicasts a DAAdvert when a subscription comes in for a
never-before-seen scope or scopes. The same algorithm should be
used. If the combination of the DA attributes and the NotifyAtExt
message cause the DAAdvert to overflow a UDP packet, DA attributes
MUST be truncated to allow the NotifyAtExt to fit and the overflow
bit must be set in the header. Multiple DAAdvert messages MUST
NOT be multicast. An SA knows that the purpose of the message
is to inform it of a new subscription rather than for passive
advertisement, because of the extension, and it can therefore ignore
the DA attribute list field if the overflow bit is set in the header.
A DA also transmits a SrvDereg message when a service advertisement
is deregistered due to timeout.
10. DA Disappearance
When a DA disappears due to unforeseen circumstances, subscription
information from UAs is lost. If a new DA is discovered, existing
SAs continue notifying UAs of their state changes until the
subscriptions expire. If no new DA is discovered, existing SAs
ignore the subscription expiration time and continue notifying SAs
until a new DA is discovered. UAs SHOULD reissue their subscriptions
to a newly discovered DA the next time they perform an SLP query
or when they renew their subscription. However, there is a window
between when the old DA disappears and when the UAs reissue their
subscriptions in which any newly starting SAs are not informed of the
outstanding subscriptions. UAs that are concerned about receiving
notification of absolutely every service that appears SHOULD issue
subscriptions to every newly discovered DA that supports the scopes
it supports. Similarly, if a DA disappears through a controlled
shutdown, a UA performing passive discovery can detect the shutdown
and reissue the subscriptions to an alternate DA.
11. Network Administration Considerations
In SLP networks with DAs as described in RFC 2608, the only multicast
is the SrvRqst for DAAdverts performed during active DA discovery,
and unsolicited DAAdverts sent periodically by the DA for passive
discovery. There is no multicast involved in UA queries or SA
registrations. This allows network administrators to set up DAs
Kempf and Goldschmidt Expires 22 March 2000 [Page 9]
Internet Draft Notification and Subscription for SLP 22 October 1999
for a particular collection of IP subnets and confine all service
discovery traffic to unicast between the SA and UA clients and the
DA. Administratively scoped multicast can additionally be used to
limit the extent of active DA discovery and passive DA advertising.
The amount of multicast involved is not high and DHCP DA and scope
configuration can be used to limit the DAs that a particular UA or
SA client sees, or to inhibit multicast entirely so that UAs and SAs
only use configured DAs.
With notification, however, multicast traffic involving events in SAs
becomes available. Because DAs request multicast addresses based on
scope, the multicast associated with particular events should only
propagate to those subnets in which UAs and SAs of the same scope
are interacting. Routers should be configured with administrative
multicast scoping to limit multicast. If DAs are not deployed (or
the MAAA is not deployed), however, the amount of multicast on the
SLP multicast address when notifications are being used could quickly
become very large. Therefore, it is crucial that DAs supporting
notification be deployed in large networks where UA clients are
interested in notification.
12. Security Considerations
The SrvReg and SrvDereg messages contain authentication blocks for
all SLP SPIs supported by the DAs with which the SA registers. Since
these SPIs are necessarily the same as those that UAs can verify, a
UA receiving a multicast notification is in a position to verify the
notification. It does so by selecting the authentication block or
blocks that it can verify. If authentication fails, either due to
lack of an authentication block, or lack of the proper SPI, the UA
simply discards the notification. In a network without DAs, the SPIs
of the UA and SA must also match.
13. Acknowledgements
The authors would like to thank Charles Perkins, of Nokia, and
Erik Guttman and Jonathan Wood, of Sun Microsystems, for their
stimulating discussion and suggestions during the initial phases of
the subscription/notification design.
References
[1] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service
Location Protocol. RFC 2608, July 1999.
Kempf and Goldschmidt Expires 22 March 2000 [Page 10]
Internet Draft Notification and Subscription for SLP 22 October 1999
[2] E. Guttman, C. Perkins, J. Kempf Service Templates and service:
Schemes RFC 2609, July 1999.
[3] S. Bradner. Key Words for Use in RFCs to Indicate Requirement
Levels. RFC 2119, March 1997.
[4] D. Meyer. Administratively Scoped IP Multicast. RFC 2365, July
1998.
[5] D. Crocker and P. Overell. Augmented BNF for Syntax
Specifications: ABNF. RFC 2234, November 1997.
[6] http://www.iana.org/in-notes/iana/assignments/multicast-addresses
[7] Hanna, S., B. Patel, M. Shah Multicast Address Dynamic Client
Allocatin Protocol (MADCAP) draft-ietf-malloc-madcap-XX.txt A
work in progress
14. Full Copyright Statement
Copyright (C) The Internet Society (1997). 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."
Kempf and Goldschmidt Expires 22 March 2000 [Page 11]
Internet Draft Notification and Subscription for SLP 22 October 1999
Authors' Addresses
James Kempf Jason Goldschmidt
Sun Microsystems C0318 Bucknell University
UMPK15-214 Lewisburg, PA, 17837
901 San Antonio Rd. USA
Palo Alto, CA 94040
USA
Phone: +1 650 786 5890 +1 570 577 5624
Email: james.kempf@sun.com jgoldsch@acm.org
Kempf and Goldschmidt Expires 22 March 2000 [Page 12]