Internet Engineering Task Force Erik Guttman
INTERNET DRAFT
Category: Informational
January 4, 2002
Expires in six months
The serviceid: URI Scheme for Service Location
draft-guttman-svrloc-serviceid-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Comments on this document should be sent to the SLP discussion list,
srvloc-discuss@lists.sourceforge.net.
Internet-Drafts are draft documents of the Internet Engineering Task
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." See http://www.ietf.org/ietf/1id-abstracts.txt.
Find shadow directories at http://www.ietf.org/shadow.html.
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
The Service Location Protocol (SLP) allows clients to discover
services with little or no prior configuration. SLP can be used to
advertise services of any kind through the use of URLs. However, SLP
uses URLs for two purposes: as a LOCATOR (indicating the location of
the service) and as an IDENTIFIER (used for subsequent operations on
a service, such as registration, deregistration and looking up
attributes.) Confounding these two functions in one object leads to
certain problems. The serviceid: scheme separates identification
from location, eliminating these problems.
1. Introduction
The Service Location Protocol, Version 2 [RFC2608] [RFC2608bis]
allows services to advertise themselves, by associating four objects
together in a service advertisement:
- Scope list
A comma delimited list of strings that denote an administrative
grouping of services.
- Service Type
A string representing the type of service. The service type can
be abstract (such as "directory-service") or concrete (such as
Guttman, E. Expires: 4 July 2002 [Page 1]
Internet Draft SLPv2 Revision January 2002
"ldapv3").
- Service URL
A URL that serves two purposes: [1] IDENTIFICATION: The URL is
used to reregister, deregister or query the attributes of a
service advertisement. [2] LOCATION: The URL may include the
location of the service being registered, in the form of the IP or
other network address or the host name.
- Attributes
A list of attribute tag/typed value list pairs. The value list may
be empty.
Confounding the identification and location functions into a single
object, namely the service URL, leads to the following problems:
1. Identifying a logically single service available at multiple
locations.
Currently, separate SLP service advertisements must be made for
each location of a service. As a result, it is impossible to
establish the identity of a logically single service that is
available through multiple locations. Specifically, a multihomed
host offering the same service on multiple interfaces, or a host
offering the same service at different ports cannot be
distinguished from a case when separate services are offered at
different locations. For example, are "http://a.example.com",
"http://b.example.com" and "http://b.example.com:2346" distinct
services or rather distinct access points for the same service?
Since the URL is used for both location and identification,
there is no way to determine the identity of several services
from URLs which encode different locations.
2. Identifying a service that is accessable through multiple
protocols.
Some services support multiple protocols. For example, a single
multiprotocol printer may support IPP, LPR, and raw tcp network
printing job delivery. Currently, the printer must advertise
URLs for each protocol and each URL has only one scheme
indicating the protocol to use to contact the printer. Are the
URLs "service:printer:lpr://example.com" and
"service:printer:ipp://example.com" a single printer service
which speaks two protocols or two distinct services? It is not
possible to determine, from a set of distinct URLs, whether they
refer to different services or the same service instance
accessable through different protocols.
3. The service URL contains no way to indicate which transport
protocol to use to access a service.
Guttman, E. Expires: 4 July 2002 [Page 2]
Internet Draft SLPv2 Revision January 2002
Some protocols can be accessed via either UDP or TCP.
Additional transports, such as RTP, or SCTP may be used to
access servers. The current SLP service URL provides no way to
determine whether a particular service is accessable through a
particular transport protocol. Even if the transport protocol
were encoded in the URL, it would still not be possible to
determine if the service supported more than one transport
protocol, and if so, which one. This information may be useful
for a client capable of utilizing more than one transport
protocol, so the client can determine which protocol to use to
contact a particular service.
4. Discovering the current location of particular service
A client may need some way to specify that the location of a
particular service should be discovered again, even if the
service location was changed. SLP should be able to discover
the same printer on successive occasions, even if the printer's
network location changes. Currently, in SLP, there is no way to
specify a unique identifier for the service so that a client can
rediscover the same service.
These problems have been difficult to overcome using the mechanisms
SLP currently provides.
One solution to these problems is to use a URI that is a pure
identifier and has no locator semantics. The service associated with
this identifier then has a set of attributes that includes all the
information needed to solve the five problems listed above. This
solution is used in the SLP service type template for IPP [IPP], but
it is limited by the current semantics of SLP service URLs. Having
an identifier URL would simplify and standardize support for services
that require separation between location and identification.
In order to make use of the service URL scheme, a service must
generate a unique identifier. The service SHOULD store this
persistently, so that the the service is always advertised the same
id. An example of how to generate a universally unique identifier
(UUID) is described in [ISO-11578]; however, any method that is
sufficiently random can be used [RFC1750].
2. URI syntax
The URI syntax is as follows:
service-id-uri = "serviceid:" 1*(HEXDIGIT / "-")
The URI simply encodes the unique ID associated with a service. Each
byte of the ID is encoded as two HEXDIGIT values. Arbitrary dashes
("-") may be introduced to increase human readability. This
identifier is not, however, intended for human readability, nor does
Guttman, E. Expires: 4 July 2002 [Page 3]
Internet Draft SLPv2 Revision January 2002
it encode the location of a service. The location and description of
the service is instead present in the attributes registered with the
service advertisement.
3. Service Templates for Advertising Services via serviceid: URIs
The attributes described below SHOULD be registered with any service
that uses the 'serviceid:' scheme. [RFC2609] describes the service
template syntax and how to use it. Note that the template fragment
shown below is not a complete template, but rather text to include in
any template that uses the serviceid: scheme.
---------------------Template fragment starts here----------------------
service-hi-name=string
# This is a human readable name of the service for purpose of displaying
# in a human interface.
service-hi-description=string O
# This is a human readable description of the service for the purpose of
# displaying in a human interface.
service-id=string
# This is a text rendering of unique identifier. It contains the same value
# that appears in the "serviceid:" URI registered with the
# service.
service-location-tcp=string M
# This attribute contains a list of strings. The strings are
# the URLs giving the location where the service can be
# accessed via the TCP transport protocol. For example:
#
#
# (service-location=nfs://a.example.com,nfs://a.example.com,
# http://b.example.com:3421,http://b.example.com:32423)
#
service-location-udp = string M
# This attribute contains a list of strings. The strings
# are the URLs giving the location where the service can
# be accessed via the UDP transport protocol.
service-location-sctp = string M
# This attribute contains a list of strings. The strings
# are the URLs giving the location where the service can
# be accessed via the SCTP transport protocol.
service-location-xxx = string M
# Should other transport protocols come into common
# use, attributes can be added that contain the URLs
# giving the location where the service can be
Guttman, E. Expires: 4 July 2002 [Page 4]
Internet Draft SLPv2 Revision January 2002
# accessed via these transports.
----------------------Template fragment ends here-----------------------
4. How to solve common problems using 'serviceid' URLs
This section describes how the serviceid: URI and the service
attributes introduced in the preceding two sections solve the
problems described in Section 1. A UA discovers a service using a
SrvRqst, which returns the serviceid: URI. Either the SrvRqst is
followed by an AttrRqst for all attributes of the service discovered,
using that serviceid: URI as the locator in the AttrRqst, or the
original SrvRqst is sent with an Attrlist Extension [RFC3059].
4.1. Discovering services with multiple locations
The UA obtains an attribute list for each service discovered. The
transport specific service location attributes in this attribute list
indicate the multiple locations of services associated with the
service instance.
4.2. Discovering multiple protocols associated with a service
The attribute list provides a list of all protocols supported by the
service instance.
4.3. Discovering the transport protocols which a service supports
The attribute list contains transport specific service location
attributes containing the location through which the service is
accessable via a specific transport.
4.4. Discovering the current location of a particular service
The UA can construct a search filter to discover a service instance
which has been discovered previously. The search filter used in the
SrvRqst contains the following term:
"(service-id=" UUID ")"
The UUID above is replaced by the unique id of the service previously
discovered. For example, a UA discovers a service:
service type
"smtp"
scope
default
service url
"service:98432A98-B879E8FF-80342A89-43280B89C"
Guttman, E. Expires: 4 July 2002 [Page 5]
Internet Draft SLPv2 Revision January 2002
attribute list
(service-hi-name=west), (service-hi-description=west coast campus
smpt server), (service-id=98432A98-B879E8FF-80342A89-43280B89C),
(service-location-tcp=smtp://west.example.com)
The UA discovers the location of the service subsequently by issuing
an SrvRqst with an Attrlist extension:
service type
smtp
scope
default
search filter
(service-id=98432A98-B879E8FF-80342A89-43280B89C)
Or, an AttrRqst for
service url
service-id:98432A98-B879E8FF-80342A89-43280B89C
scope
default
If the attributes are successfully retrieved, the current attribute
list includes the location of the service,
which may have changed since the last time it was discovered.
4.5 Ease of use
The service-hi-name and service-hi-description attribute values
simplify producing human interfaces for service browsing. The user
need never see the unique identifer attribute, as there is a human
readable name provided for display. Since attributes can be
registered in multiple languages, the name and description can be
internationalized, as appropriate.
5. Open issues
An alternative to the "serviceid:" scheme is to simply use the
"data:" URL scheme and include the unique ID data following it.
[RFC2397] This would not necessitate the standardization of a new
URL scheme, but it would be a bit less clear what the function of the
registered URI is.
Acknowledgments
James Kempf contributed significantly to this specification.
Guttman, E. Expires: 4 July 2002 [Page 6]
Internet Draft SLPv2 Revision January 2002
References
[IPP] Flemming, P., et. al., "Internet Printing Protocol (IPP):
LDAP Schema for Printer Services", draft-ietf-ipp-ldap-printer-
schema-05.txt, a work in progress.
[ISO-11578] ISO (International Organization for Standardization).
ISO/IEC 11578:1996. "Information technology - Open Systems
Interconnection - Remote Procedure Call (RPC)"
[RFC1750] Eastlake, D., et. al, "Randomness Recommendations for
Security", RFC 1750, September 1994.
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC 2608] E. Guttman, et. al, "Service Location Protocol version 2",
RFC 2608, June 1999.
[RFC2608bis] Guttman, E, Kempf, J., "Service Location Protocol, Version
2", draft-guttman-svrloc-rfc2608bis-01.txt, December 2001, a
work in progress.
[RFC 2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
service: Schemes", RFC 2609, June 1999.
[RFC3059] Guttman, E., "Attribute List Extension for the Service
Location Protocol", RFC 3059, February 2001.
Author's Contact Information
Erik Guttman
Sun Microsystems
Eichhoelzelstr. 7
74915 Waibstadt Germany
erik.guttman@sun.com
Guttman, E. Expires: 4 July 2002 [Page 7]