Subject: SLP for Capabilities Discovery

From: James Kempf <[email-masked]>
Date: Wed, 21 Apr 1999 14:51:36 -0700 (PDT)

Attached is an Internet draft showing how Service Location Protocol (SLP)
could be used for resource capabilities discovery on the Internet.
Slight modifications in protocol usage, not inconsistent with the
standard protocol, and some naming conventions are proposed to allow
SLP to fit into the Internet environment. While the draft makes a strong
case for using SLP as a resource discovery mechanism, the point of the
draft is not to push SLP explicitly but rather to show how an existing
protocol for discovery and directory services can be used to fill
the resource discovery niche and to suggest that existing
protocols should be intensively considered as candidates before any new 
protocols are designed.

A working prototype of the design will be available shortly on the Internet, if
anyone cares to try it out. The prototype does not use the naming
conventions described in the draft, nor does it limit registrations
from the Internet, because it additionally serves as an interoperability
test bed for anyone who wants to test their SLP implementations against
Sun's. The prototype is available at the following location:

SLP scope: da.suntd.net
port: 427 (standard SLP port)
hostname: da.suntd.net
IP Address: 205.180.52.2

There will be three fictitious registered service:mailto URLs that
conform to the example description given in the draft. You could
simply use an SLP SrvRqst to query for them, but if you just
want to use an AttrRqst to query for the capabilities, the URLs are:

service:mailto://coca.mo/joe.schmo
service:mailto://coca.mo/joe.schmo-jr
service:mailto://coca.mo/joes.wife

All registrations are in the English (en) locale.

The prototype should be working by tomorrow, April 22.

		jak

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 [email-masked] 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:[email-masked]

   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:    [email-masked]

Kempf                 Expires 15 October 1999                  [Page 16]

---

From: [email-masked]
Date: Thu, 22 Apr 1999 13:55:44 -0700

>SLP to fit into the Internet environment.

What you propose, if I understand it correctly, sounds great, and is in
fact something we've been kicking around here a bit as well.

For those unfamiliar with the Macintosh side of the world, a brief bit of
background.  Apple included an implementation of SLP v1 with Mac OS 8.5,
which shipped last year.  In January, Open Door Networks (my company) added
SLP support to our ShareWay IP product line.  ShareWay IP
(http://www.opendoor.com/ShareWay/) lets any Apple Filing Protocol (AFP)
server provide Macintosh file service over TCP/IP.  It is most often used
with the Mac's built-in personal file sharing, which previously only worked
over AppleTalk.  With SLP and ShareWay IP, both the ease-of-use and the
functionality of AppleTalk-based file service is now available over IP.

SLP of course currently only works over intranets, but we've been working
with Apple to figure out how to expand its functionality to an Internet
environment.  What we came up with, I believe, is basically what you
propose.  An organization which wanted to make AFP (or other) services
publically available over the Internet would simply set up a DA with a list
of such services.  A client (UA) on the Internet would connect to that DA
(either through knowing that DA's host name or some other mechanism) and
obtain the list of available URLs.  The UA could then display that list for
the user, who could point-and-click as they do today.  It would be very
cool.

Is what I'm suggesting here doable under your proposal?  I think it is, but
want to be sure.  One thing I don't understand is the need for a new port
number on the DA.  Is that just to prevent someone from being able to add
services from the Internet side?  If so, it would seem there would be other
ways of preventing this.  It seems to me that it would be best if no new
port needed to be used, since just about everything else from the protocol
perspective remains the same.  It would be great if a UA always did the
same thing, regardless of whether it was talking to an intranet or
Internet-based DA.

+-----+
|     |   Alan Oppenheimer
|     |   Open Door Networks, Inc.
|o    |   Internet solutions as easy to use as the Macintosh itself
|     |   [email-masked]
|     |   http://www.opendoor.com
+-----+

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 24 Apr 1999 11:26:09 -0700

This is an interesting proposal. However, I think it attacks the wrong
problem for the wrong reasons. It also has some pretty gaping holes
that might be able to be fixed later, but show that in fact that SLP
probably doesn't match what folks want rescap to do.

 >SLP to fit into the Internet environment.

I'm not convinced that this is the case. According to RFC 2165, SLP is
specifically designed to be used in local area networks, not the global
Internet. Although you provide a method for changing the latter, it is
not at all clear that the rest of the protocol will withstand such a
change. Given the thin current deployment of SLP, and given that all of
the deployment heavily relies on the parts that need to be taken out to
make this useful for rescap, it is premature to assume that such a
fundamental change will work.

 >probably be deployed internally as well.

 From the start, the abstract misstates the purpose of rescap. rescap is
not for discovering resources, it is for resolving attributes of known
resources. This is (I think) pretty clear from the charter. Maybe it
should be made clearer in the John's requirements draft. SLP is really
for discovering services, but rescap isn't.

 >Developers would then have
 >the server side.

Arguing that "clients can misuse a protocol" does not lead to
"therefore don't create the protocol". If it did, we would never have
gotten HTTP. Using a rescap protocol to do service discovery would
indeed be stupid and wasteful.

 >An added benefit of this design is that Internet
 >discovery.

Warning, Will Robinson! These are two unrelated items. No one doing
resource capability queries needs to do service discovery at the same
time. If I'm asking "what are the MUA capabilities of
[email-masked]?" I don't need to know anything about any service. It
sounds like you're using this extension of SLP to get it more widely
deployed.

 >clients to discover resources and capabilities associated with a URL.

Rescap is only about capabilities, not about resources. The URL
already states the resource.

 >in co-operatively managed, internal networks as well.

This does not seem to be a "danger" to me.

 >  Developers
 >inferior to the current choices in a fundamental way.

See comments above. Arguing that we need to use a redesigned SLP
because some bonehead might use rescap to discover services is
not a reasonable way to design a protocol. You might as well
argue that firewalls should be configured to prevent users from
pinging each port on a host to see if the host has a particular
service on it.

 >  With this

A bit of evidence for this last statement would be in order.

 >basic requirements for a wide area resource discovery protocol.

Again, rescap is not about resource discovery, it's about resource
capability resolution. You don't use rescap to find out if the
resource "mailto:[email-masked]" exists, but to find out what
capability that resource has. It is absurd to think that someone
will use a dictionary attack on every possible name that would appear
in a URL to do resource discovery.

 > . . .

I'm sorry, but I think this is a non-starter. There is no defined way
for an application client to determine whether or not IPsec is or is
not in place, much less if it is being used to encrypt traffic. The way
that RFC 2165 got around this was to say "Because the objective of this
protocol is to advertise services to a community of users,
confidentiality might not generally be needed when this protocol is
used in non-sensitive environments." But rescap is specifically *not*
limited to a community of users, so saying "no confidentiality" is not
acceptable.

 > . . .

I don't know SLP well enough to evaluate this, but I don't see in
section 20.2 of RFC 2165 how to include particular attributes in the
request. You didn't include any examples in your draft of requests for
specific attributes.

In summary, I don't think this protocol matches the needs stated
in the rescap charter, nor necessarily all the needs specified in
the requirements document. I also don't think it is a good idea
to modify basic parts of another unrelated protocol that has not been
heavily used just to prevent creating a new protocol that might be
very simple and much more focused.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: [email-masked]
Date: Mon, 26 Apr 1999 08:09:27 -0700

>for discovering services, but rescap isn't.

I think this statement may be key to resolving this discussion.  I'm
unfamiliar with rescap, so I can't be sure.  What I do know (which I
previously stated in this thread) is that is seems SLP (with only very
minor, if any, modifications) seems like a great protocol to do what I call
"domain-focused Internet-wide" service discovery.  That is, given a domain,
what services are publically available within that domain?  As I mentioned,
we have been working with Apple to extend their implementation of SLP to
allow pretty much what was proposed in the message that started this whole
thread.  With such an extension, a user would be able to go to
da.opendoor.com or da.apple.com and get a human-readable list of publically
available services within those domains.

So I'd leave it to "the experts" to determine how SLP relates to rescap,
but I'd very much like to encourage the continued exploration of any
extensions to SLP which might be needed to provide what to us seems like a
critical piece of functionality.  Exactly what that functionality is called
seems secondary.

+-----+
|     |   Alan Oppenheimer