< draft-ietf-svrloc-template-conversion-07.txt		draft-ietf-svrloc-template-conversion-08.txt >
	INTERNET DRAFT James Kempf		INTERNET DRAFT James Kempf
	Category: Informational Sun Microsystems, Inc.		Category: Informational Sun Microsystems, Inc.
	Title: draft-ietf-svrloc-template-conversion-07.txt Ryan Moats		Title: draft-ietf-svrloc-template-conversion-08.txt Ryan Moats
	Date: June 2000 AT&T Laboratories		Date: July 2000 Coreon, Inc.
	Pete St. Pierre		Pete St. Pierre
	Sun Microsystems, Inc.		Sun Microsystems, Inc.
	Conversion of LDAP Schemas to and from SLP Templates		Conversion of LDAP Schemas to and from SLP Templates
	Status of this Memo		Status of this Memo
	This document is an individual contribution for consideration by the		This document is an individual contribution for consideration by the
	SrvLoc Working Group of the Internet Engineering Task Force.		SrvLoc Working Group of the Internet Engineering Task Force.
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	even be impossible. The second aspect is representation of service		even be impossible. The second aspect is representation of service
	information in an LDAP directory. The recommended representation		information in an LDAP directory. The recommended representation
	simplifies interoperability with SLP by allowing SLP directory agents		simplifies interoperability with SLP by allowing SLP directory agents
	to backend into LDAP directory servers. The resulting system allows		to backend into LDAP directory servers. The resulting system allows
	service advertisements to propagate easily between SLP and LDAP.		service advertisements to propagate easily between SLP and LDAP.
	Table of Contents		Table of Contents
	1.0 Introduction		1.0 Introduction
	2.0 Mapping SLP Templates to LDAP Schema		2.0 Mapping SLP Templates to LDAP Schema
	2.1 Mapping from SLP Attribute Types to LDAP Attibute Types		2.1 Mapping from SLP Attribute Types to LDAP Attribute Types
	2.1.1 Integer		2.1.1 Integer
	2.1.2 String		2.1.2 String
	2.1.3 Boolean		2.1.3 Boolean
	2.1.4 Opaque		2.1.4 Opaque
	2.2 Keyword Attributes		2.2 Keyword Attributes
	2.3 Template Flags		2.3 Template Flags
	2.3.1 Multi-valued		2.3.1 Multi-valued
	2.3.2 Optional		2.3.2 Optional
	2.3.3 Literal		2.3.3 Literal
	2.3.4 Explicit Matching		2.3.4 Explicit Matching
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 29 ¶
	Network services are an example of one such entity.		Network services are an example of one such entity.
	Interoperability between SLP and LDAP is important so clients using		Interoperability between SLP and LDAP is important so clients using
	one protocol derive benefit from services registered through the		one protocol derive benefit from services registered through the
	other. In addition, LDAP directory servers can serve as the backend		other. In addition, LDAP directory servers can serve as the backend
	for SLP directory agents (DAs) if interoperability is possible In		for SLP directory agents (DAs) if interoperability is possible In
	order to facilitate interoperability, this document creates mappings		order to facilitate interoperability, this document creates mappings
	between the SLP template grammar and LDAP directory schema, and		between the SLP template grammar and LDAP directory schema, and
	establishes some conventions for representing service advertisements		establishes some conventions for representing service advertisements
	in LDAP directories. The goal of the translation is to allow SLPv2		in LDAP directories. The goal of the translation is to allow SLPv2
	queries (which are syntatically and semantically equivalent to LDAPv3		queries (which are syntactically and semantically equivalent to
	string queries [7]) to be submitted to an LDAP directory server by an		LDAPv3 string queries [7]) to be submitted to an LDAP directory
	SLP DA backended into LDAP without extensive processing by the DA.		server by an SLP DA backended into LDAP without extensive processing
			by the DA.
	The simple notation and syntactic/semantic attribute capabilities of		The simple notation and syntactic/semantic attribute capabilities of
	SLP templates map easily into directory schemas, and are easily		SLP templates map easily into directory schemas, and are easily
	converted into directory schemas, even by automated means. The		converted into directory schemas, even by automated means. The
	reverse may not be true. If the LDAP schema contains attributes with		reverse may not be true. If the LDAP schema contains attributes with
	unrecognized or complex syntaxes, the translation may be difficult or		unrecognized or complex syntaxes, the translation may be difficult or
	impossible. If, however, the LDAP schema only uses a few of the		impossible. If, however, the LDAP schema only uses a few of the
	common syntaxes defined in RFC 2252 [8], then the translation is		common syntaxes defined in RFC 2252 [8], then the translation is
	more straightforward. In addition, to foster complete		more straightforward. In addition, to foster complete
	bidirectionality, the mapping must follow a very specific		bidirectionality, the mapping must follow a very specific
	representation in its DESC attributes.		representation in its DESC attributes.
	This document outlines the correct mappings for SLP templates into		This document outlines the correct mappings for SLP templates into
	the syntatic representation specified for LDAP directory schema by		the syntactic representation specified for LDAP directory schema by
	RFC 2252 [8]. This syntax is a subset of the ASN.1/BER described in		RFC 2252 [8]. This syntax is a subset of the ASN.1/BER described in
	the X.209 specification [9], and is used by the LDAPv3 [2] directory		the X.209 specification [9], and is used by the LDAPv3 [2] directory
	schema. Likewise, rules and guidelines are proposed to facilitate		schema. Likewise, rules and guidelines are proposed to facilitate
	consistent mapping of ASN.1 based schemas to be translated in the SLP		consistent mapping of ASN.1 based schemas to be translated in the SLP
	template grammar. Finally, a proposal for a representation of service		template grammar. Finally, a proposal for a representation of service
	advertisements in LDAP directory services is made that facilitates		advertisements in LDAP directory services is made that facilitates
	SLP interoperability.		SLP interoperability.
	Except when used as elements in the definition of LDAP schemas, the		Except when used as elements in the definition of LDAP schemas, the
	key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 6, line 4 ¶		skipping to change at page 6, line 5 ¶
	SINGLE-VALUE		SINGLE-VALUE
	)		)
	The template-url-syntax definition in the SLP template is described		The template-url-syntax definition in the SLP template is described
	by the following attribute:		by the following attribute:
	( 1.3.6.1.4.1.6252.2.27.6.1.3		( 1.3.6.1.4.1.6252.2.27.6.1.3
	NAME 'template-url-syntax'		NAME 'template-url-syntax'
	DESC 'An ABNF grammar describing the service type		DESC 'An ABNF grammar describing the service type
	specific part of the service URL'		specific part of the service URL'
	EQUALITY caseExactIA5Match		EQUALITY caseExactIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26		SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
	SINGLE-VALUE		SINGLE-VALUE
	)		)
	The template-description attribute is translated into the X.520		The template-description attribute is translated into the X.520
	standard attribute ``description'' [3].		standard attribute ``description'' [3].
	We further establish the convention that SLP template characteristcs		We further establish the convention that SLP template characteristics
	that can't be translated into LDAP are inserted into the DESC field		that can't be translated into LDAP are inserted into the DESC field
	of the object class definition. The items are separated by empty		of the object class definition. The items are separated by empty
	lines (consisting of two "LINE FEED" characters), are preceeded by a		lines (consisting of two "LINE FEED" characters), are preceded by a
	LINE FEED character, and are tagged at the beginning of the line to		LINE FEED character, and are tagged at the beginning of the line to
	indicate what they represent. This allows the template to be		indicate what they represent. This allows the template to be
	reconstructed from the schema by properly parsing the comments.		reconstructed from the schema by properly parsing the comments.
	The bulk of an SLP template consists of attribute definitions. There		The bulk of an SLP template consists of attribute definitions. There
	are four items in an SLP template attribute definition that need to		are four items in an SLP template attribute definition that need to
	be mapped into LDAP:		be mapped into LDAP:
	Attribute Name - Since SLPv2 attribute names are defined to be		Attribute Name - Since SLPv2 attribute names are defined to be
	compatible with LDAPv3, SLP attributes map directly into LDAP		compatible with LDAPv3, SLP attributes map directly into LDAP
	attributes with no change. Similarly, LDAP attributes map directly		attributes with no change. Similarly, LDAP attributes map directly
	to SLP attributes.		to SLP attributes.
	Attribute Type - The SLP attribute type is mapped into the LDAP		Attribute Type - The SLP attribute type is mapped into the LDAP
	attribute type.		attribute type.
	Attribute Flags - The SLP attribute flags are mapped into		Attribute Flags - The SLP attribute flags are mapped into
	characterics of the LDAP attribute definition, or into the DESC		characteristics of the LDAP attribute definition, or into the DESC
	field if no equivalent LDAP attribute definition characteristic		field if no equivalent LDAP attribute definition characteristic
	occurs.		occurs.
	Default and Allowed Values - These must be handled by the client or		Default and Allowed Values - These must be handled by the client or
	a DA enabled to handle templates, as in SLP. For reference,		a DA enabled to handle templates, as in SLP. For reference,
	however, they should be included in the DESC field of the LDAP		however, they should be included in the DESC field of the LDAP
	attribute definition.		attribute definition.
	Descriptive Text - The SLP template descriptive text should be		Descriptive Text - The SLP template descriptive text should be
	mapped into the DESC field.		mapped into the DESC field.
	We discuss mapping of types, flags, default and allowed values, and		We discuss mapping of types, flags, default and allowed values, and
	descriptive text in the subsections below.		descriptive text in the subsections below.
			OIDs for SLP template conversion schema elements are standardized
			under the enterprise number of SrvLoc.Org (6252) [18].
	For purposes of representing an SLP entry, we also define two		For purposes of representing an SLP entry, we also define two
	standardized LDAP syntaxes and attributes with standardized OIDs.		standardized LDAP syntaxes and attributes with standardized OIDs.
	( 1.3.6.1.4.1.6252.2.27.6.2.2		( 1.3.6.1.4.1.6252.2.27.6.2.2
	DESC 'SLP Service Type'		DESC 'SLP Service Type'
	)		)
	Defines the syntax for the service type name. The syntax is defined		Defines the syntax for the service type name. The syntax is defined
	in the BNF for the service URL in RFC 2609 Section 2.1 [1].		in the BNF for the service URL in RFC 2609 Section 2.1 [1].
	skipping to change at page 8, line 13 ¶		skipping to change at page 8, line 16 ¶
	(service-advert-service-type=service:printer:*)		(service-advert-service-type=service:printer:*)
	SLP specifies that service URLs and attribute lists can be		SLP specifies that service URLs and attribute lists can be
	accompanied by a structured authenticator consisting of a digital		accompanied by a structured authenticator consisting of a digital
	signature and information necessary to verify the signature. A		signature and information necessary to verify the signature. A
	syntax and two standardized SLP attributes are defined for this		syntax and two standardized SLP attributes are defined for this
	purpose:		purpose:
	( 1.3.6.1.4.1.6252.2.27.6.2.3 DESC 'SLP Authenticator')		( 1.3.6.1.4.1.6252.2.27.6.2.3 DESC 'SLP Authenticator')
	The syntax of an SLP authenticator is a sequence of bytes in		The syntax of an SLP authenticator is the bytes of the
	network byte order preceeded by the number of bytes in the		authenticator in network byte order, see RFC 2608, Section 9.2 [5].
	sequence, encoded as an INTEGER. The contents of the sequence are
	the bytes from the SLP authentication block, see RFC 2608, Section
	9.2 [5].
	( 1.3.6.1.4.1.6252.2.27.6.1.6		( 1.3.6.1.4.1.6252.2.27.6.1.6
	NAME 'service-advert-url-authenticator'		NAME 'service-advert-url-authenticator'
	DESC 'The authenticator for the URL, null if none.'		DESC 'The authenticator for the URL, null if none.'
	SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.3		SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.3
	SINGLE-VALUE		SINGLE-VALUE
	)		)
	This attribute contains the SLP URL authenticator, as defined in		This attribute contains the SLP URL authenticator, as defined in
	RFC 2608, Section 9.2 [5].		RFC 2608, Section 9.2 [5].
	skipping to change at page 10, line 6 ¶		skipping to change at page 10, line 8 ¶
	2.2 Keyword Attributes		2.2 Keyword Attributes
	SLP service type templates allow the definition of keyword		SLP service type templates allow the definition of keyword
	attributes. Keyword attributes are attributes whose only		attributes. Keyword attributes are attributes whose only
	characteristic is their presence. Keyword attributes have no flag		characteristic is their presence. Keyword attributes have no flag
	information, nor any default or allowed values (since, by definition,		information, nor any default or allowed values (since, by definition,
	they have no values).		they have no values).
	ASN.1 has no concept of keyword attributes. Keyword attributes are		ASN.1 has no concept of keyword attributes. Keyword attributes are
	translated into a ``May'' clause in the ASN.1 class defintion for the		translated into a ``May'' clause in the ASN.1 class definition for
	service type. If the keyword attribute is present, then its value is		the service type. If the keyword attribute is present, then its value
	of no consequence, but for consistency we make it simply the NUL		is of no consequence, but for consistency we make it simply the NUL
	character, `` 0''.		character, ``\00''.
	2.3 Template Flags		2.3 Template Flags
	SLP template flags can be handled as described in the following		SLP template flags can be handled as described in the following
	subsections.		subsections.
	2.3.1 Multi-valued		2.3.1 Multi-valued
	Multi-valued attributes are defined in an SLP template using the one		Multi-valued attributes are defined in an SLP template using the one
	value. All values for a given attribute must be of the same type.		value. All values for a given attribute must be of the same type.
	skipping to change at page 11, line 21 ¶		skipping to change at page 11, line 23 ¶
	or alternatively it may also be used by DAs to initialize		or alternatively it may also be used by DAs to initialize
	registrations having no attributes and to limit attribute values to		registrations having no attributes and to limit attribute values to
	the template allowed values.		the template allowed values.
	LDAP servers also do not support default and allowed values on		LDAP servers also do not support default and allowed values on
	attributes. Therefore, enforcement of default and allowed values in		attributes. Therefore, enforcement of default and allowed values in
	SLP templates is left up to the clients or a DA, if the DA is		SLP templates is left up to the clients or a DA, if the DA is
	backending into LDAP. The default and allowed values should be		backending into LDAP. The default and allowed values should be
	included in the DESC field. The comments should be placed on separate		included in the DESC field. The comments should be placed on separate
	lines and labeled with the ``Default:'' and ``Allowed:'' tags to		lines and labeled with the ``Default:'' and ``Allowed:'' tags to
	allow reconstruction of the tempalte.		allow reconstruction of the template.
	2.5 Descriptive Text		2.5 Descriptive Text
	The descriptive text associated with an attribute definition should		The descriptive text associated with an attribute definition should
	be included in the DESC field. It should start on a separate line and		be included in the DESC field. It should start on a separate line and
	begin with the ``Description:'' tag.		begin with the ``Description:'' tag.
	2.6 Generating LDAP Attribute OIDs		2.6 Generating LDAP Attribute OIDs
	LDAP attributes require an OID. In general, there is no a priori way		LDAP attributes require an OID. In general, there is no a priori way
	skipping to change at page 19, line 9 ¶		skipping to change at page 19, line 9 ¶
	provides no specific support for transmitting enumerations. They are		provides no specific support for transmitting enumerations. They are
	simply String types. Information on the ASN.1 type and ASN.1 encoding		simply String types. Information on the ASN.1 type and ASN.1 encoding
	of the enumeration values is recorded in the comment.		of the enumeration values is recorded in the comment.
	Example:		Example:
	color-supported = STRING M		color-supported = STRING M
	none		none
	# ASN.1: Enumeration.		# ASN.1: Enumeration.
	# ASN.1 Mapping: none = 0, highlight = 1, three color = 2, four color = 4,		# ASN.1 Mapping: none = 0, highlight = 1, three color = 2, four color = 4,
	# monochrmatic = 5		# monochromatic = 5
	#This attribute specifies whether the Printer supports		#This attribute specifies whether the Printer supports
	# color and, if so, what type.		# color and, if so, what type.
	none,highlight,three color,four color,monochromatic		none,highlight,three color,four color,monochromatic
	4.2.4 Object Identifier		4.2.4 Object Identifier
	Object identifiers(OIDs) are commonly used in the ASN.1 world to		Object identifiers(OIDs) are commonly used in the ASN.1 world to
	identify object and attributes. OIDs are a numerical representation		identify object and attributes. OIDs are a numerical representation
	of an element's place in the naming hierarchy. Each element at a		of an element's place in the naming hierarchy. Each element at a
	particular level of a hierarchy has a unique number assigned within		particular level of a hierarchy has a unique number assigned within
	skipping to change at page 20, line 14 ¶		skipping to change at page 20, line 14 ¶
	4.3 Example ASN.1 Schema		4.3 Example ASN.1 Schema
	The following is an example schema for an exported filesystem. The		The following is an example schema for an exported filesystem. The
	section presents it as in ASN.1 and the following section shows the		section presents it as in ASN.1 and the following section shows the
	SLP template translation. The template translation does not capture		SLP template translation. The template translation does not capture
	the actual attribute format for the Set type, that would be done in		the actual attribute format for the Set type, that would be done in
	the LDAP client software making the translation. Note that even		the LDAP client software making the translation. Note that even
	though the class definition does not conform with the previously		though the class definition does not conform with the previously
	defined conventions for SLP classes, the schema can still be		defined conventions for SLP classes, the schema can still be
	translated into an SLP template.		translated into an SLP template. The syntax used in this example
			follows
	-- abstraction of a fstab entry (a "mount")
	-- these lookups would likely be performed by an
	-- an automounter type application
	mount OBJECT-CLASS
	SUBCLASS OF top
	MUST CONTAIN {
	-- the mount host
	mountHost,
	-- the mount point
	mountDirectory.
	-- the mount type
	mountType
	}
	MAY CONTAIN {
	-- mount options
	mountOption,
	-- dump frequency
	mountDumpFrequency,
	-- passno
	mountPassNo
	}
	mountHost OBJECT-TYPE		-- Abstraction of a fstab entry (a "mount").
	SYNTAX Case Ignore String		-- These lookups would likely be performed by an
	DESCRIPTION		-- an automounter type application.
	"The mount host"		mount OBJECT-CLASS ::= {
			SUBCLASS OF { top }
			MUST CONTAIN { mountHost |
			mountDirectory |
			mountType
			}
			MAY CONTAIN { mountOption |
			mountDumpFrequency |
			mountPassNo
			}
			ID { <oid1> }
			}
	mountDirectory OBJECT-TYPE		- The mount host.
	SYNTAX Case Ignore String		mountHost ATTRIBUTE ::= {
	DESCRIPTION		WITH SYNTAX caseIgnoreString
	"The filesystem to mount"		EQUALITY MATCHING RULE caseIgnoreMatch
			SINGLE VALUE
			ID { <oid2> }
			}
	mountType OBJECT-TYPE		- The file system to mount.
	SYNTAX INTEGER {		mountDirectory ATTRIBUTE ::= {
	ufs(1)		WITH SYNTAX caseIgnoreString
	hsfs(2)		EQUALITY MATCHING RULE caseIgnoreMatch
	nfs(3)		SINGLE VALUE
	rfs(4)		ID { <oid3> }
	}		}
	DESCRIPTION		- The type of file system being mounted.
	"The type of the filesystem being mounted"		mountType ATTRIBUTE ::= {
			WITH SYNTAX INTEGER { ufs(1),
			hsfs(2),
			nfs(3),
			rfs(4)
			}
			EQUALITY MATCHING RULE integerMatch
			SINGLE VALUE
			ID { <oid4> }
			}
	mountOption OBJECT-TYPE		- Options for the mount operation.
	SYNTAX SET OF Case Ignore String		mountOption ATTRIBUTE ::= {
	DESCRIPTION		WITH SYNTAX caseIgnoreString
	"mount options for this filesystem"		EQUALITY MATCHING RULE caseIgnoreString
			ID { <oid5> }
			}
	mountDumpFrequency OBJECT-TYPE		- How often to dump the file system.
	SYNTAX INTEGER (0..9)		mountDumpFrequency ATTRIBUTE :: = {
	DESCRIPTION		WITH SYNTAX INTEGER (0..9)
	"How often to dump this filesystem"		EQUALITY MATCHING RULE integerMatch
			SINGLE VALUE
			ID { <oid6> }
			}
	mountPassNo OBJECT-TYPE		- Boot time mount pass number.
	SYNTAX Integer		mountPassNo ATTRIBUTE ::= {
	DESCRIPTION		WITH SYNTAX INTEGER
	"Boot time mount pass number"		EQUALITY MATCHING RULE integerMatch
			SINGLE VALUE
			ID { <oid7> }
			}
	The translated SLP template is:		The translated SLP template is:
	template-type = mount		template-type = mount
	template-version = 1.0		template-version = 1.0
	template-description = "Describes a remote filesystem access protocol"		template-description = "Describes a remote filesystem access protocol"
	template-url-syntax =		template-url-syntax =
	filesystem = 1*[ DIGIT / ALPHA ]		filesystem = 1*[ DIGIT / ALPHA ]
	urlpath = "/" filesystem		urlpath = "/" filesystem
	mountHost = STRING L		mountHost = STRING L
	# ASN.1: Case Ignore String		# ASN.1: Case Ignore String, Single Value
	# The mount host		# The mount host
	mountDirectory = STRING L		mountDirectory = STRING L
	# ASN.1: Case Ignore String		# ASN.1: Case Ignore String, Single Value
	# The filesystem to mount		# The filesystem to mount
	mountType = STRING L		mountType = STRING L
	ufs		ufs
	# ASN.1: Enumeration		# ASN.1: Enumeration, Single Value
	# ASN.1 Mapping: ufs = 1, hsfs = 2, nfs = 3, rfs = 4		# ASN.1 Mapping: ufs = 1, hsfs = 2, nfs = 3, rfs = 4
	# The type of the filesystem being mounted		# The type of the filesystem being mounted
	ufs, hsfs, nfs, rfs		ufs, hsfs, nfs, rfs
	mountOption = STRING M O L		mountOption = STRING M O L
	# ASN.1: Set of Case Ignore String		# ASN.1: Case Ignore String
	# mount options for this filesystem		# mount options for this filesystem
	mountDumpFrequency = INTEGER O		mountDumpFrequency = INTEGER O
	0		0
	# ASN.1: Integer Range		# ASN.1: Integer Range, Single Value
	# How often to dump this filesystem		# How often to dump this filesystem
	0, 1, 2, 3, 4, 5, 6, 7, 8, 9		0, 1, 2, 3, 4, 5, 6, 7, 8, 9
	mountPassNo = INTEGER O		mountPassNo = INTEGER O
	# ASN.1: Integer		# ASN.1: Integer, Single Value
	# Boot time mount pass number		# Boot time mount pass number
	5.0 Representing SLP Service Advertisments in an LDAP DIT		5.0 Representing SLP Service Advertisments in an LDAP DIT
	In addition to translating between SLP templates and LDAP schema,		In addition to translating between SLP templates and LDAP schema,
	another area requiring compatibility is the representation of SLP		another area requiring compatibility is the representation of SLP
	service advertisements in an LDAP DIT. A standardized representation		service advertisements in an LDAP DIT. A standardized representation
	for service information allows SLP DAs to store service		for service information allows SLP DAs to store service
	advertisements in LDAP, and for LDAP clients to query the DIT for		advertisements in LDAP, and for LDAP clients to query the DIT for
	those services. Similarly, if LDAP clients represent service		those services. Similarly, if LDAP clients represent service
	information in the same form, SLP clients can benefit from		information in the same form, SLP clients can benefit from
	interoperability.		interoperability.
	A service advertisement contains the service URL in a 'labeledURI'		A service advertisement contains the service URL in a 'labeledURI'
	attribute [11]. The labeledURI attribute in a service advertisement		attribute [11]. The labeledURI attribute in a service advertisement
	should only contain the service URL for the service, with no		should only contain the service URL for the service, with no
	additional label.It is recommended that the labeledURI be used as the		additional label. It is recommended that the labeledURI be used as
	RDN for the service object in the DIT.		the RDN for the service object in the DIT.
	Although service advertisements can appear anywhere within the DIT,		Although service advertisements can appear anywhere within the DIT,
	it is recommended that all services be stored under a single common		it is recommended that all services be stored under a single common
	point to facilitate searching in a domain. This allows a client to		point, or root node, to facilitate searching in a domain. This allows
	search for all of advertisements of a particular service type, say,		a client to search for all of advertisements of a particular service
	for all printers. The recommended parent entry is one named		type, say, for all printers. The recommended parent entry is one
	"ou=service" below the entry which is the representation of the		named "ou=service" below the entry which is the representation of the
	domain, as described in RFC 2247.		domain, as described in RFC 2247.
	For example, a printer service with labeledURI of		For example, a printer service with labeledURI of
	"service:lpr://printsrv/queue1" in the domain foobar.com would be		"service:lpr://printsrv/queue1" in the domain foobar.com advertised
	advertised in the LDAP server that holds the entry "dc=foobar,dc=com"		in the LDAP server that holds the entry "dc=foobar,dc=com" tree has
	tree would have the following DN:		the following DN:
	"labeledURI=service:lpr://printsrv/queue1, ou=service, dc=foobar, dc=com"		"labeledURI=service:lpr://printsrv/queue1, ou=service, dc=foobar, dc=com"
	While this leads to a flat space of service storage, since SLP uses		While this leads to a flat space of service storage, since SLP uses
	search filters from LDAP for searches, these filters can be used for		search filters from LDAP for searches, these filters can be used for
	one-level searches from the root node.		one-level searches from the root node.
	The following example illustrates how an advertisement having a		The following example illustrates how an advertisement having a
	simple service type is represented. The advertisment (in conceptual		simple service type is represented. The advertisment (in conceptual
	form) for a printer is:		form) for a printer is:
	skipping to change at page 23, line 28 ¶		skipping to change at page 23, line 41 ¶
	Authentication: none		Authentication: none
	The RDN of the object is labeledURI=service:lpr://printsrv/queue1,		The RDN of the object is labeledURI=service:lpr://printsrv/queue1,
	and the following LDAP search filter will return this object, along		and the following LDAP search filter will return this object, along
	with any others of the service type ``service:lpr'' that match the		with any others of the service type ``service:lpr'' that match the
	other attributes:		other attributes:
	(&(service-advert-service-type=service:lpr)		(&(service-advert-service-type=service:lpr)
	(service-advert-scopes=eng)		(service-advert-scopes=eng)
	(service-advert-scopes=corp)		(service-advert-scopes=corp)
	(description=A general printer for all to use)		(description=A general printer for all to use.)
	(security-mechanisms-supported=none))		(security-mechanisms-supported=none))
	Service advertisements in SLP also have a lease time associated with		Service advertisements in SLP also have a lease time associated with
	them. In LDAP servers that support the extensions for dynamic		them. In LDAP servers that support the extensions for dynamic
	directory services [12], the service advertisement entry objectClass		directory services [12], the service advertisement entry objectClass
	should be extended with the dynamicObject class. This allows the		should be extended with the dynamicObject class. This allows the
	service advertisment to time out within the LDAP directory server. If		service advertisment to time out within the LDAP directory server. If
	the LDAP directory server does not support the dynamic directory		the LDAP directory server does not support the dynamic directory
	services extension, then advertisement lease timeouts must be handled		services extension, then advertisement lease timeouts must be handled
	by the SLP agent.		by the SLP agent.
	skipping to change at page 24, line 38 ¶		skipping to change at page 25, line 4 ¶
	SLP authenticators are stored with the service advertisement in the		SLP authenticators are stored with the service advertisement in the
	DIT, as discussed in Section~7ef{slpdit}. LDAP clients need to use		DIT, as discussed in Section~7ef{slpdit}. LDAP clients need to use
	LDAP authentication [15] to assure that they are connecting with a		LDAP authentication [15] to assure that they are connecting with a
	secure server. In particular, SLP DAs that use LDAP as a back end		secure server. In particular, SLP DAs that use LDAP as a back end
	store and that implement SLP authentication MUST use LDAP		store and that implement SLP authentication MUST use LDAP
	authentication to assure that the LDAP entries for their service		authentication to assure that the LDAP entries for their service
	registrations are secure.		registrations are secure.
	Acknowledgements		Acknowledgements
	Many thanks are due to Mark Wahl whose detailed and insightful		Many thanks are due to Mark Wahl whose detailed and insightful
	comments were instrumental in helping improve the technical accuracy		comments were instrumental in helping improve the technical accuracy
	of this draft with respect to LDAP.		of this draft with respect to LDAP.
	7.0 References		8.0 References
	[1] E. Guttman, C. Perkins, J. Kempf. Service Templates and service:		[1] E. Guttman, C. Perkins, J. Kempf. Service Templates and service:
	Schemes. RFC 2609, April, 1999.		Schemes. RFC 2609, April, 1999.
	[2] M. Wahl, T. Howes, and S. Kille. Lightweight Directory Access		[2] M. Wahl, T. Howes, and S. Kille. Lightweight Directory Access
	Protocol (v3). RFC 2251, December, 1997.		Protocol (v3). RFC 2251, December, 1997.
	[3] International Telecommunications Union. The Directory:Selected		[3] International Telecommunications Union. The Directory:Selected
	Attribute Types. ITU Recommendation X.520. August, 1997.		Attribute Types. ITU Recommendation X.520. August, 1997.
	skipping to change at page 25, line 50 ¶		skipping to change at page 26, line 15 ¶
	[14] M. Wahl and T. Howes. Use of Language Codes in LDAP. RFC 2596.		[14] M. Wahl and T. Howes. Use of Language Codes in LDAP. RFC 2596.
	May, 1999.		May, 1999.
	[15] M. Wahl, H. Alvestrand, J. Hodges, and R. Morgan. Authentication		[15] M. Wahl, H. Alvestrand, J. Hodges, and R. Morgan. Authentication
	Methods for LDAP. draft-ietf-ldapext-authmeth-xx.txt. Work in		Methods for LDAP. draft-ietf-ldapext-authmeth-xx.txt. Work in
	Progress.		Progress.
	[16] S. Bradner. Key Words for Use in RFCs to Indicate Requirement		[16] S. Bradner. Key Words for Use in RFCs to Indicate Requirement
	Levels. RFC 2119. March 1997.		Levels. RFC 2119. March 1997.
			[17] Dubuisson, O. ASN.1: Communication between Heterogeneous
			Systems. OSS Nokalva, 2000.
			[18] http://www.srvloc.org
	9.0 Full Copyright Statement		9.0 Full Copyright Statement
	Copyright (C) The Internet Society (1997). All Rights Reserved.		Copyright (C) The Internet Society (1997). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implmentation may be prepared, copied, published and		or assist in its implementation may be prepared, copied, published
	distributed, in whole or in part, without restriction of any kind,		and distributed, in whole or in part, without restriction of any
	provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for		developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be		copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than		followed, or as required to translate it into languages other than
	English.		English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	skipping to change at page 26, line 33 ¶		skipping to change at page 27, line 8 ¶
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
	10.0 Authors' Address		10.0 Authors' Address
	James Kempf Ryan Moats		James Kempf Ryan Moats
	Sun Microsystems AT&T Laboratories		Sun Microsystems Coreon, Inc.
	901 San Antonio Avenue 15621 Drexel Circle		901 San Antonio Avenue 15621 Drexel Circle
	Palo Alto, CA 94303 Omaha, NE, 68135		Palo Alto, CA 94303 Omaha, NE, 68135
	USA		USA
	Phone: +1 650 786-5890 +1 402 894-9456		Phone: +1 650 786-5890
	Email: james.kempf@sun.com jayhawk@att.com		Email: james.kempf@sun.com rmoats@coreon.net
	Pete St. Pierre		Pete St. Pierre
	Sun Microsystems		Sun Microsystems
	901 San Antonio Avenue		901 San Antonio Avenue
	Palo Alto, CA 94303		Palo Alto, CA 94303
	USA		USA
	Phone: +1 415 786-5790		Phone: +1 415 786-5790
	Email: Pete.StPierre@Eng.Sun.COM		Email: Pete.StPierre@Eng.Sun.COM
End of changes. 37 change blocks.
	98 lines changed or deleted		113 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/