Internet Engineering Task Force James Kempf
INTERNET DRAFT Sun Microsystems
15 April 1999
iSLP: Resource Discovery on the Internet with Service Location Protocol
draft-kempf-slp-rescap-00.txt
Status of This Memo
This document is a submission by the Resource Capabilities Discovery
Working Group of the Internet Engineering Task Force (IETF).
Comments should be submitted to the rescap@cs.utk.edu 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.
Kempf Expires 15 October 1999 [Page i]
Internet Draft iSLP 15 April 1999
Abstract
The danger in defining a new protocol specifically for discovering
resources on the Internet is that, like DNS, the protocol would
probably be deployed internally as well. Developers would then have
the opportunity to use the protocol to perform service discovery on
the client side by downloading resources and inferencing over them
rather than using protocols such as Service Location Protocol (SLP)
or Lightweight Directory Access Protocol (LDAP) that inference on
the server side. Besides the increased amount of network traffic
involved in transferring attributes rather than the smaller query,
every client would need to incorporate its own inferencing code. In
this document, we discuss how the requirements for wide area resource
discovery can be met by slightly modifying SLP to remove features
more appropriate for internal networks and by establishing a few
naming conventions. An added benefit of this design is that Internet
clients can perform service discovery as well as simple resource
discovery. It should be noted the proposals in this document are not
meant to suggest that SLP is the only or even the best candidate for
Internet resource discovery among existing protocols. The point of
this paper is to emphasize the need for a concerted effort to make an
existing discovery or directory services protocol fill the Internet
resource discovery niche, rather than inventing yet another protocol
offering discovery or directory services capabilites.
Kempf Expires 15 October 1999 [Page ii]
Internet Draft iSLP 15 April 1999
Contents
Status of This Memo i
Abstract ii
1. Introduction 1
2. Terminology 2
3. Design Overview 3
4. DA Discovery 3
5. Scopes 4
6. Security 5
7. Referrals 6
8. Additional Considerations 6
9. Requirements Analysis 7
9.1. Resolution Protocol Requirements . . . . . . . . . . . . 7
9.2. Administrative Update Protocol Requirements . . . . . . . 8
10. Mail Capabilities Template 8
11. Operational Experience 9
12. Summary 9
13. Appendix A - MailTo URL Template 10
14. Full Copyright Statement 15
Kempf Expires 15 October 1999 [Page iii]
Internet Draft iSLP 15 April 1999
1. Introduction
Interest has recently been expressed in a protocol to allow Internet
clients to discover resources and capabilities associated with a URL.
The primary application is for identifying properties associated
with email users, but other applications are envisioned as well.
The protocol is envisioned to scale like DNS, requiring similar
performance and security characteristics. Unfortunately, the danger
in developing a new protocol is that, like DNS, it will be deployed
in co-operatively managed, internal networks as well. Developers
will then have yet another choice for doing service discovery
(current choices are DNS, DHCP, SLP, and LDAP), but one that is
inferior to the current choices in a fundamental way. With this
protocol, clients would be required to download the attributes
for all URLs of interest and inference over them on the client
side, rather than allowing the server to perform the inferencing.
Besides the increase in network traffic involved in cycling through
attributes for different URLs, the inferencing code would need to
be duplicated in each client rather than centralized in the server.
Some network application developers will undoubtably tend to use this
mechanism instead of the more efficient existing mechanisms.
The original design intent of the Service Location Protocol
(SLP) [1] was to provide a framework for discovering and configuring
network services on co-operatively managed networks internal to an
organization. The design includes certain features (multicast, DHCP
configuration) that are not appropriate on the global Internet.
Yet, the fundamental features of the protocol - discovery of
services and resources associated with those services - satisfy the
basic requirements for a wide area resource discovery protocol.
The specification of UDP as the base transport mechanism for SLP
(with TCP failover in the event the information overflows a single
datagram) means that SLP could be a fast performer on the Internet.
Because SLP was designed for a high degree of compatibility with
LDAP [5], SLP clients and servers integrate well with network
directory services. With proper configuration, an internally
deployed SLP network could export service advertisements to Internet
clients, simplifying administration. Finally, SLP includes features
for security to allow the client to authenticate information provided
by the server.
In this document, we propose modifications to SLP to allow operation
on the global Internet. These modifications, called Internet SLP
or iSLP, are specifically oriented toward SLP operation on the
Internet, and are not intended to update or modify the SLP standard
for internal networks as defined in [1]. An added benefit of this
proposal is that Internet clients can discover services exported from
a DNS domain using SLP. This document does not propose to use SLP for
finding services across the global Internet, however.
Kempf Expires 15 October 1999 [Page 1]
Internet Draft iSLP 15 April 1999
It should be noted this document is not meant to suggest that SLP
is the only or the best candidate for Internet resource discovery
among existing discovery and directory service protocols. Allowing
UDP access to LDAP directory servers and additional security are
examples of two changes that might make LDAP an appropriate protocol
for Internet resource discovery, for example. Other changes may be
needed as well. The point of this paper is to emphasize the need
for a concerted effort to make an existing discovery or directory
services protocol fill the Internet resource discovery niche, rather
than inventing yet another protocol offering services similar to
discovery and directory services.
2. Terminology
We reproduce here some SLP terminology from [1] for readers unfamilar
with SLP.
User Agent (UA)
A process working on the user's behalf to establish
contact with some service. The UA retrieves service
information from the Service Agents or Directory Agents.
Service Agent (SA)
A process working on behalf of one or more services to
advertise the services and their capabilites.
Directory Agent (DA)
A process which collects service advertisements. There
can only be one DA present per given host.
Scope A set of services, typically making up a logical
administrative group.
URL A Universal Resource Locator [3].
Service Advertisement
A URL, attributes, and a lifetime (indicating how
long the advertisement is valid), providing service
access information and capabilities description for a
particular service.
SPI
A Security Parameters Index that indicates what
algorithm parameters, keying material, etc. to use when
verifying a signed SLP advertisement.
Kempf Expires 15 October 1999 [Page 2]
Internet Draft iSLP 15 April 1999
3. Design Overview
The modifications required to allow SLP operation on the
Internet primarily involve dropping mechanisms that work well on
co-operatively managed, internal networks but would not scale outside
of such networks. Alternative mechanisms are required in certain
cases. The diagram illustrates the basic design.
+-------+ -Unicast AttrRqst-> +-----------+
| User | | Directory |
| Agent | | Agent |
+-------+ <-Unicast AttrRply- +-----------+
A client User Agent, or UA, contacts through the Internet a
Directory Agent, or DA, for the DNS domain associated with the URL
for which capabilities information is required. A standard SLP
AttrRqst/AttrRply message pair is used to conduct the transaction.
The UA uses unicast UDP to contact the DA, and the DA replies
with unicast UDP. If the information won't fit into a single UDP
packet, the SLP header overflow bit is set by the DA, and the UA can
optionally contact the DA again via TCP. The UA can additionally
obtain service type and service information from the DA by using
the standard SLP SrvTypeRqst/SrvTypeRply and SrvRqst/SrvRply,
respectively.
Note that, unlike SLP on internal networks, the design does not
include Service Agents (SAs). That is, the DA must not accept SrvReg
or SrvDereg messages from the Internet. The only two entities
involved are UAs and DAs. The purpose of the DA is to export
services and capabilities from within the domain to clients on the
Internet, not for services to be registered from the Internet.
For this reason, and because the procedure used by UAs to discover
DAs is considerably different, DAs on the Internet require a
port number different from the standard SLP port number (427). A
different port number also allows the DA to accept SrvReg messages
internally, for services to be exported, on port 427 and to export
them via the new port, simplifying administration.
4. DA Discovery
SLP contains a multistep procedure for discovering DAs. The
procedure works well for networks having a variety of sizes. Because
it depends on multicast and DHCP, it won't work on the Internet
however.
We define two ways allowing UAs to discover DAs on the Internet:
Kempf Expires 15 October 1999 [Page 3]
Internet Draft iSLP 15 April 1999
1. For DNS domains that do not deploy DNS SRV RRs or that have
only one directory agent, the conventional names ``sda'' and
``da'' are reserved for SLP directory agents with and without
authenticated service advertisements, respectively. Thus,
an IP address for a directory agent without authenticated
advertisements in the domain ``onesrv.net'' can be obtained by
resolving the name ``da.onesrv.net''.
2. For DNS domains that deploy DNS SRV RRs and that have more than
one directory agent, ``da'' and ``sda'' can be used to obtain a
list of DA addresses for the domain.
This procedure exactly parallels current practice for finding
Internet addresses of servers offering services such as FTP, NTS, and
the World Wide Web (WWW), namely a conventional name that resolves to
the machine address or a list of DNS SRV RRs for machines offering
the service.
Like http and https [4], the design uses separate names for accessing
authenticated and unauthenticated DAs. SLP requires the inclusion of
a Security Parameters Index (SPI) into a request if a signed reply is
desired. The SPI must be left off if no authentication is required.
If an SPI is included and the DA does not provide authentication, or
vice versa, an error reply is sent. By reserving separate names for
authenticated and unauthenticated access, the UA is spared having
to process an error reply if it should happen to contact a DA that
needs security but the UA doesn't supply an SPI, or vice versa. More
information on how security in handled is provided below.
5. Scopes
Every SLP request issued by the UA requires that a list of scope
names be included. Scopes are a way of provisioning services into
groups. Within an enterprise, a network administrator can use
scopes to group services by department, building floor, or any other
criteria. The UA discovers its scopes either through DHCP or by
actively discovering available DAs and the scopes they support.
Neither DHCP nor active DA discovery is supported on the Internet, so
another mechanism is required.
In order to simplify scope discovery, iSLP requires some way to allow
the client UA to inference the scope name without having to do much
computation. One way is to have a DA on the Internet use its fully
qualified domain name (FQDN) as the scope name. If a domain exports
DAs via DNS SRV RRs, the scope name is the FQDN obtained from the SRV
RR. For example, in the case sited above of a single DA in the domain
``onesrv.net'', the FQDN ``da.onesrv.net'' is used as the scope name.
If the network administrator adds another DA on machine ``twosrv''
Kempf Expires 15 October 1999 [Page 4]
Internet Draft iSLP 15 April 1999
and configures DNS SRV RRs for the machines, the new machine supports
the scope ``twosrv.onesrv.net'' and the machine ``da'' continues to
support the scope ``da.onesrv.net''.
A critical property of the design is that the scope name is known a
prior by the UA as soon as it knows the machine name for the DA. This
speeds querying because the UA need not perform an initial query to
the DA to discover the scope name.
Unlike the internal network case, however, the design does not
explicitly allow multiple DAs to service queries for the same scope
to achieve load balancing. Other mechanisms must be used for load
balancing in iSLP.
6. Security
In order for a UA to make a query on a DA containing authenticated
advertisements, the UA must present the DA with an SPI of an SA
that has registered authenticated information with the DA. The DA
itself does not sign service advertisements. The SPI determines
the algorithm, keying parameters, and other material to use when
decrypting the response from the DA. The SLP protocol and the SLP
DHCP extension contain no specification of how the SPI is configured,
since that is a system-dependent feature. The UA must include an
SPI in all requests for authenticated service advertisements, or the
requests are rejected with an AUTHENTICATION_UNKNOWN error. The
SPI in the request and the SPI supported by the SA that registered
the service advertisement with the DA must match because the SPI
determines whether the UA has the right cryptomaterial to handle the
digital signatures included with the reply. The algorithm used to
authenticate the digital signature is DSA with SHA-1 [6].
Since there is no way to a priori configure UAs with individual
SPIs on the Internet, some mechanism is required whereby the UA can
identify itself to the DA as having already obtained the proper
cryptomaterial. The actual exchange of the cryptomaterial itself is
outside the scope of the protocol, and may take place by a PKI [8] or
other means. We use the FQDN of the UA as the SPI. During a previous
exchange of cryptomaterial, the domain offering the capabilites DA
records the FQDN of the UA. This name is then used as the SPI when
contacting the DA for capabilities information.
The process of obtaining authenticated capabilities proceeds as
follows. A UA issues the AttrRqst including its FQDN as the SPI.
The DA responds with the capabilities information and a structured
authenticator. The authenticator includes the certificate authority
(CA) of the SA that registered the capabilites. If the UA has access
to a PKI, it can use the CA to obtain the public key of the SA. If
Kempf Expires 15 October 1999 [Page 5]
Internet Draft iSLP 15 April 1999
the UA does not have access to a PKI, it must have direct access to
the the SA's public key through a prior exchange. In either case,
the UA uses the public key to decrypt the digital signature and
authenticate the reply.
Note that, in this process, the DA is acting purely as a cache for
the authenticated advertisement (as it does for all advertisements)
and the trust relationship is established end to end, between the UA
on the Internet and the SA internal to the domain that is advertising
the capabilities.
Again, as is typically the case in SLP, the design contains no
provision for privacy or encryption of the information exchange
between the DA and UA. Should privacy be required, a security
association should be set up and IPSec [7] used.
7. Referrals
While SLP provides no explicit support for referrals, referrals
can be handled by an attribute, say the ``referral'' attribute,
on service registrations that contains the referral URL. If the
client wants to make sure that it catches any referrals, it needs to
include the ``referral'' attribute in the AttrRqst for the service
capabilities. Alternatively, the client can simply make the request
for the capabilities it needs, and if an empty reply is returned,
it can make another request to see if the capabilities DA has a
referral. Typically, a URL for which only a referral exists will
have no attributes except for the ``referral'' attribute.
8. Additional Considerations
The SLP protocol specifies that if a reply to a SrvRqst overflows
a UDP datagram, it must be formatted such that the UA could use
the partial reply if it chose not to failover to TCP to obtain the
full reply [1]. No such restrictions are placed on SrvTypeRqst or
AttrRqst. In order to allow Internet clients to use partial replies,
this restriction must be extended to SrvTypeRqst and AttrRqst. The
comma-separated lists in these requests must be properly formatted
(i.e. no truncated information) for the UA to use.
An added benefit of using SLP for resource capabilities discovery is
that the SLP service type definition mechanism can be used to define
resources. [2]. The service type template definition mechanism
allows simple definitions of attributes for service: URLs. This
provides a basis whereby clients and servers can agree on what a
service type definition is. Alternatively, the URLs for which
Kempf Expires 15 October 1999 [Page 6]
Internet Draft iSLP 15 April 1999
capability information is advertised need not be service: URLs. SLP
allows information to be advertised for URLs having generic schemes.
9. Requirements Analysis
This section reviews how closely iSLP matches the requirements
outlined in [10].
9.1. Resolution Protocol Requirements
This section describes how SLP fufills the resolution protocol
requirements.
Scalability
The design of SLP contains no features that should hamper
a high performance implementation. A medium performance
implementation that caches service advertisements in memory
handles around 200 transations per second and has been tested
at over 20,000 advertisements but this could certainly be
improved upon.
Long Replies
SLP allows a client to call back using TCP if a query reply
overflows UDP.
Granularity
SLP allows subsets of attributes to be fetched, and allows
the full set to be fetched without knowing the entire set of
attribute tags.
Expiration
SLP service advertisements are registered with a time to live.
Referral
The ``referral'' attribute described in Section 7 provides
referral capability.
Privacy
SLP handles authenticated transactions. Encrypted transactions
would require IPSec [7].
Kempf Expires 15 October 1999 [Page 7]
Internet Draft iSLP 15 April 1999
Server Location
As outlined above, iSLP uses DNS SRV records to locate Internet
DAs.
Preference
Preferred values can be handled by including an attribute
indicating which value from a set is preferred, or by arranging
the values into a prioritized list, as is done in for the
example mail template in Section 10
9.2. Administrative Update Protocol Requirements
The administrative update protocol in this case is the standard SLP
protocol operating within the domain. This includes the ability
to register and deregister capabilities advertisements. The
following list indicates how SLP fufills the administrative protocol
requirements.
Access Control
SLP uses scopes to achieve access control. Only capabilities
advertisements registered within the exported scope will be
visible to clients outside the domain.
Privacy
SLP supports digital signatures on capabilities advertisements.
Signed advertisements may only be updated in their entirety,
and only by advertisements having a signature.
Inheritance
SLP formally supports one level of inheritence of attributes.
A concrete service type inherits attributes from its
abstract service type template. Other inheritence can be
arranged informally, as there is no enforcement of particular
relationships between descriptions of different service types
in the SLP protocol itself.
10. Mail Capabilities Template
Appendix A contains a service type template [2] for the proposed
mail capabilites schema [9], which is the cannonical resources
capabilities application. This template could be used by SLP SAs
within a domain to advertise the capabilities of a service: URL that
Kempf Expires 15 October 1999 [Page 8]
Internet Draft iSLP 15 April 1999
describes a mailto URL for export to the Internet. An example of a
service:mailto URL is the following:
service:mailto://coca.mo/joe.schmo
This translates into the following mailto URL:
mailto:joe.schmo@coca.mo
Service type templates are only defined for service: URLs, but SLP
also allows applications to register any valid URL, so the mailto URL
itself could be used for registering mail capabilities.
The mail capabilities schema described in [9] contains prioritized
lists of values for certain capabilities. As is the case with LDAP,
SLP multivalued attributes have no ordering, so these lists are
represented in the template as strings formatted as a comma separated
list. An example is the following list:
US-ASCII,UTF-8,UNICODE
This is a prioritized list of charsets, with US-ASCII being first
priority, UTF-8 second, and UNICODE third. If the prioritized list
is for binary items, the items are in SLP opaque format.
11. Operational Experience
Sun has been running an SLP DA on the Internet for about 4 months
as of this writing. Although we have not set up the naming
conventions discussed in this article, the DA does no multicast
passive advertising, and UA clients on the Internet are required to
statically configure the host name and scope in order to contact it
(i.e. not use DHCP). In addition, Sun has not deployed security for
the Internet DA.
12. Summary
By dropping mechanisms specific to internal, co-operatively managed
networks and substituting a few simple naming conventions, iSLP DAs
can serve as high capacity sources of information on resources and
capabilities accessable to UA clients on the Internet. iSLP DAs
Kempf Expires 15 October 1999 [Page 9]
Internet Draft iSLP 15 April 1999
accept no service registrations from the Internet; rather, they act
as a mechanism for exporting services and capabilities from a DNS
domain and advertising them to the world. Since iSLP DAs run on a
different port, a DA implementation can accept registrations on the
standard SLP port from within the domain, and reflect the service
advertisements out onto the Internet through the Internet port.
Internal users can either use the internal SLP port for standard SLP
queries or the external port.
An added bonus is that service type information and attribute
based queries for exported services can be made by iSLP UA clients.
Clients can therefore use iSLP to discover what services are exported
from the domain. The iSLP is not a general solution for wide
area service location, however, since the client must direct the
attribute-based query to a specific domain rather than simply sending
it off to the Internet. In addition, iSLP is not the only possible
solution to the resource discovery problem on the Internet.
13. Appendix A - MailTo URL Template
template-type = mailto
template-version = 0.0
template-description =
This template describes a resource capabilites schema for describing
the resources associated with email users in a domain. The
standard mailto URL is converted into a service:mailto URL to
advertise the capabilites. Note that prioritized lists are represented
in this template as comma-separated lists, and lists of binary
items are represented using the SLP string binary encoding. The
template also includes a ``referral'' attribute for referrals,
if the domain being queried knows where the attributes are located.
url-syntax = path = user-name
user-name = ;The mailto URL's user name, see mailto URL for syntax.
HandlesMIME = Boolean L O
#Conforms to the general checklist for MIME conformance, as described
#in RFC 2049.
MIMEHeaderExtensions = Boolean L O
#Conforms to the extensions for MIME headers, such as for non-ASCII characters,
#as described in RFC 2047.
MIMEParamExtensions = Boolean L O
#Conforms to the extensions for MIME parameter values and encoded words,
#as described in RFC 2231.
Kempf Expires 15 October 1999 [Page 10]
Internet Draft iSLP 15 April 1999
DisplayableMedia = String L O
#A list of MIME types and subtypes in Conneg String format that are natively
#displayed by the receiving MUA without falling back to a default media
#type. This string should contain only MIME types and subtypes,
#not additional media features. The list format is described in
RFC 2553 as extended by draft-ietf-conneg-feature-type.
MediaFeatures = String L O
#A list of media features of the MUA in Conneg String format, described
#in RFC 2553.
CharsetsDisplayed = String L O
#A prioritized list attribute containing charset labels that describe the
#charsets that can be displayed. The list items are in the form of
#RFC 2278.
PreferredLanguages = String L O
#A prioritized list of languages understandable to the recipient. List
#items are formatted as described in RFC 1766.
HandlesMHTML = Boolean L
#Handles MHTML content natively, as described in RFC 2110.
HandlesContentDisposition = String L O
#Handles Conetent-Disposition headers, as described in
#draft-newman-mime-cdisp-metadata. The strings must be "inline",
#"attachment", and "metadata". If the MUA doesn't handle any
#Content-Disposition headers, then the attribute should not be registred.
HandlesContentMD5 = Boolean L O
#Handles Conetent-MD5 headers, as described in RFC 1864.
HandlesMailingListURLs = Boolean L O
#Handles mailing list URL headers, as described in RFC 2369.
HandlesPlainFormat = Boolean L O
#Handles the "format" parameter for the text/plain MIME
#type, as described in draft-gellens-format.
HandlesOnePassMultipart = Boolean L O
#Handles the "types" parameter for the
#multipart/alternative MIME type, as described in
#draft-lundblade-1pass-mult-alt.
RepliesToMDNs = Boolean L O
#Is able to reply to message disposition notification
#requests, as described in RFC 2298. Note that this does not mean that the
#client will necessarily send an MDN back to a particular request, just
Kempf Expires 15 October 1999 [Page 11]
Internet Draft iSLP 15 April 1999
#that it is able to reply to such requests.
CalendarClient = Boolean L O
#Can act as an iCalendar iMIP agent RFC 2447.
FaxSimpleClient = Boolean L O
#Acts as a simple mode Internet FAX receiving agent RFC 2305.
FaxExtendedClient = Boolean L O
#Acts as a extended mode Internet FAX receiving agent RFC 2532.
SMIMEVerifiesSigned = String L O
#Prioritized list of signatures. Indicates that the recipient can verify
#the signatures on S/MIME signed messages. The strings in the list indicate
#the type of signatures accepted. The values currently are limited to
"id-dsa" and "rsaEncryption".
SMIMESigningCertsBasic = String L O
Value type: List of binary
#A prioritized list of S/MIME certificates for public signing keys
#of the recipient. The list members are in SLP opaque format.
SMIMESigningCertsExtended = String L O
#A prioritized list of S/MIME certificates for public signing keys
of the recipient, including additional signed attributes, as described
in draft-ietf-smime-certdist. The list members are in SLP opaque format.
SMIMEEncryptingCerts = String L O
#A prioritized list of S/MIME certificates for public encrypting
#keys of the recipient. The list members are in SLP opaque format.
SMIMEHigherCerts = OPAQUE L O M
#An unprioritized collection of S/MIME certificates for certificate
#authorities that have signed the recipient's signing and encrypting
#certificates. These higher-level certificates can be used by the sender
#to validate the recipient's certificates.
SMIMESignedReceipts = Boolean L O
#Responds to requests for S/MIME signed receipts described
#in draft-ietf-smime-ess.
SMIMESecurityLabels = Boolean L O
#Acts on S/MIME security labels, or is behind a gateway
#that does security label handling, as described in draft-ietf-smime-ess.
SMIMESecureMailingList = Boolean L O
#Is a a mailing list that uses secure mailing list handling described
#in draft-ietf-smime-ess.
Kempf Expires 15 October 1999 [Page 12]
Internet Draft iSLP 15 April 1999
SMIMEHandlesSigningCert = Boolean L O
#Handles the signed SigningCertificate attribute described
#in draft-ietf-smime-ess.
OpenPGPVerifiesSigned = String L O
#Prioritized list that indicates the recipient can verify the signatures on
#OpenPGP signed messages. The strings in the list indicate the type of
#signatures accepted. The values currently are limited to "DSA" and
#"RSA".
OpenPGPSigningCertsBasic = String L O
#Prioritized list of OpenPGP certificates for public signing keys
#of the recipient. The list members are in SLP opaque format..
OpenPGPEncryptingCerts = String L O
#Prioritized list of OpenPGP certificates for public encrypting
#keys of the recipient. The list members are in SLP opaque format.
OpenPGPHigherCerts = OPAQUE L O M
#Unprioritized collection of the OpenPGP certificates for users and
#certificate authorities that have signed the recipient's signing and
#encrypting certificates. These higher-level certificates can be used by
#the sender to validate the recipient's certificates.
UBEPreferences = String L O M
#Collection of preferences of the recipient for receiving
#unsolicited bulk email (UBE). Each attribute value is formatted
#as follows:
#
# policy ``:'' value
#
#The policy preference property is a tag indicating the law or
#policy being referred to, and the value is the specified configuration value
#for that law or policy. The identities of the laws and policies must be
#registered with IANA.
Referral = String L O M
#A collection of URLs containing referrals for other sources of
#capabilities information. Typically, if the referral attribute is present,
#it will be the only attribute since the only information the DA has
#is the location of more information.
Kempf Expires 15 October 1999 [Page 13]
Internet Draft iSLP 15 April 1999
References
[1] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service
Location Protocol. draft-ietf-svrloc-protocol-v2-12.txt A work
in progress Feburary 1999.
[2] E. Guttman, C. Perkins, J. Kempf Service Templates and service:
Schemes draft-ietf-svrloc-service-scheme-14.txt A work in
progress Feburary 1999.
[3] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource
Locators (URL): Generic Syntax and Semantics. RFC 2396, August,
1998.
[4] T. Dierks, and C. Allen. The TLS Protocol. RFC 2246, January,
1999.
[5] M. Wahl, T. Howes, S. Kille. Lighttweight Directory Access
Protocol (v3) RFC 2251, December 1997.
[6] National Institute of Standards and Technology. Digital
signature standard. Technical Report NIST FIPS PUB 186, U.S.
Department of Commerce, May 1994.
[7] R. Atkinson, and S. Kent. The IP Encapsulating Security Payload
(ESP). RFC 2406, November, 1998.
[8] N. Doraswamy, R. Glenn, and R. Thayer. IP Security Document
Roadmap. RFC 2412, November, 1998.
[9] P. Hoffman. Rescap Profile for Mail User Agents.
draft-hoffman-rescap-mua-00.txt, a work in progress.
[10] J. Beck. ResCap Requirements. draft-beck-rescap-req-00.txt, a
work in progress.
Kempf Expires 15 October 1999 [Page 14]
Internet Draft iSLP 15 April 1999
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 Expires 15 October 1999 [Page 15]
Internet Draft iSLP 15 April 1999
Authors' Addresses
James Kempf
Sun Microsystems
901 San Antonio Road
Palo Alto, CA 94040
USA
Phone: +1 650 786 5890
Email: james.kempf@sun.com
Kempf Expires 15 October 1999 [Page 16]