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]