< draft-guttman-svrloc-attrlist-ext-04.txt		draft-guttman-svrloc-attrlist-ext-05.txt >
			A new Request for Comments is now available in online RFC libraries.
	Internet Engineering Task Force Erik Guttman		RFC 3059
	INTERNET DRAFT Sun Microsystems
	16 October 2000
	Expires in six months
	Attribute List Extension for the Service Location Protocol
	draft-guttman-svrloc-attrlist-ext-04.txt
	Status of This Memo
	This document is a submission by the Service Location Working Group
	of the Internet Engineering Task Force (IETF). Comments should be
	submitted to the srvloc@srvloc.org 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.
	Abstract
	The Service Location Protocol, Version 2 provides a mechanism for a
	service to be discovered in a single exchange of messages. This
	exchange of messages does not presently include any of the service's
	attributes. This document specifies a SLPv2 extension which allows
	a User Agent to request a service's attributes be included as an
	extension to Service Reply messages. This will eliminate the need
	for multiple round trip messages for a UA to acquire all service
	information.
	Table of Contents
	Status of This Memo 1
	Abstract 1
	1. Introduction 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
	1.2. Notation Conventions . . . . . . . . . . . . . . . . . . 3
	2. Attribute List Extension 3
	3. IANA Considerations 4
	4. Internationalization Considerations 4
	5. Security Considerations 4
	6. Acknowledgments 4
	References 4
	Author's Address 5
	Full Copyright Statement 5
	1. Introduction
	The Service Location Protocol, Version 2 [3] provides a mechanism for
	a service to be discovered in a single exchange of messages. The UA
	sends a Service Request message and the DA or SA (as appropriate)
	sends a Service Reply message.
	It is clearly advantageous to be able to obtain all service
	information at once. The Service Location Protocol separates
	messages which obtain different classes of information. This
	extension enables an optimization to the basic exchange of messages,
	which currently does not include service attributes in Service Reply
	messages.
	This document specifies a SLPv2 extension which allows a User Agent
	to request that a service's attributes be included in Service Reply
	messages. This will eliminate the need for multiple round trip
	messages for a UA to acquire all service information.
	If the DA or SA does not support the SLPv2 extension, it will simply
	return a Service Reply. Support of this extension is OPTIONAL.
	1.1. Terminology
	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 the behalf of one or more services
	to advertise the services.
	Directory Agent (DA)
	A process which collects service advertisements. There
	can only be one DA present per given host.
	1.2. Notation Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [2].
	2. Attribute List Extension
	The format of the Attribute List Extension is as follows:
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Extension ID = 0x0002 | Next Extension Offset |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Offset, contd.| Service URL Length | Service URL /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Attribute List Length | Attribute List /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|# of AttrAuths |(if present) Attribute Authentication Blocks.../
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Extension ID is 0x0002.
	The Next Extension Offset value indicates the position of the next
	extension as offset from the beginning of the SLP message. If the
	next extension offset value is 0, there are no more extensions in the
	message.
	A UA sends an Attribute List Extension with a Service Request. The
	Service URL Length and Attribute List Length are set to 0 and the
	Service URL and Attribute List fields omitted in this case. The UA
	thereby requests that the SA or DA include an Attribute List
	Extension in its Service Reply by including such an 'empty' Attribute
	List Extension in the Service Request.
	A SA or DA which supports the Attribute List Extension returns one
	Attribute List extension for every URL Entry in the Service Reply
	message. The order of the Attribute List Extensions SHOULD be the
	same as the URL Entries in the Service Reply.
	The Service URL [4] identifies the corresponding URL Entry.
	The Attribute List field is the entire attribute list of the service.
	These attributes must be in the same language as that indicated in
	the Service Request message.
	If the Service Request message includes a SLP SPI string, then the
	attribute list extension MUST include an authentication block. If
	the SA or DA does not support or is unable to return an
	authentication block for the SLP SPI included in the Service Request,
	then the SA or DA MUST NOT return an Attribute List Extension. The
	format of the Attribute List extension is exactly the same as would
	be included in an Attribute Reply or Service Registration message.
	3. IANA Considerations
	According to RFC 2608:
	New SLP Extensions with types in the range 2-65535 may be
	registered following review by a Designated Expert [5].
	The extension ID number for the Attribute List Extension is 0x0002.
	This ID has been selected by the Designated Expert for SLPv2, and
	must be registered with IANA.
	4. Internationalization Considerations
	The Service Location Protocol, version 2 has mechanisms for allowing
	attributes to be transmitted with explicit language tagging [6]. The
	same mechanisms are used for this protocol extension.
	5. Security Considerations
	The Service Location Protocol, version 2 has mechanisms for allowing
	authenticators to be returned with attribute lists so that UAs are
	able to verify a digital signature over the attributes they obtain.
	This same mechanism is used for this protocol extension. The
	Attribute List Extension used in conjunction with SLPv2 is no less
	secure than SLPv2 without the extension.
	6. Acknowledgments
	The author benefited from preliminary conversations about this
	extension with Charlie Perkins.
	References
	[1] S. Bradner. The Internet Standards Process -- Revision 3. RFC
	2026, October 1996.
	[2] S. Bradner. Key Words for Use in RFCs to Indicate Requirement
	Levels. RFC 2119, March 1997.
	[3] E. Guttman, C. Perkins, J. Veizades, M. Day. Service Location
	Protocol, Version 2. RFC 2608, June 1999
	[4] E. Guttman, C. Perkins, J. Kempf. Service Templates and service:		Title: Attribute List Extension for the Service Location
	Schemes. RFC 2609, June 1999		Protocol
			Author(s): E. Guttman
			Status: Standards Track
			Date: February 2001
			Mailbox: Erik.Guttman@sun.com
			Pages: 6
			Characters: 11208
			Updates/Obsoletes/SeeAlso: None
	[5] T. Narten, H. Alvestrand. Guidelines for Writing an IANA		I-D Tag: draft-guttman-svrloc-attrlist-ext-05.txt
	Considerations Section in RFCs. RFC 2434, October 1998.
	[6] H. Alvestrand. Tags for the Identification of Languages. RFC		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3059.txt
	1766, March 1995.
	Author's Address		The Service Location Protocol, Version 2 (SLPv2) provides a mechanism
			for a service to be discovered in a single exchange of messages. This
			exchange of messages does not presently include any of the service's
			attributes. This document specifies a SLPv2 extension which allows
			a User Agent (UA) to request a service's attributes be included as an
			extension to Service Reply messages. This will eliminate the need
			for multiple round trip messages for a UA to acquire all service
			information.
	Erik Guttman		This is now a Proposed Standard Protocol.
	Sun Microsystems
	Eichhoelzelstr. 7
	74915 Waibstadt
	Germany
	Phone: +49 7263 911 701		This document specifies an Internet standards track protocol for
	Email: Erik.Guttman@sun.com		the Internet community, and requests discussion and suggestions
			for improvements. Please refer to the current edition of the
			"Internet Official Protocol Standards" (STD 1) for the
			standardization state and status of this protocol. Distribution
			of this memo is unlimited.
	7. Full Copyright Statement		This announcement is sent to the IETF list and the RFC-DIST list.
			Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	Copyright (C) The Internet Society (1999). All Rights Reserved.		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	This document and translations of it may be copied and furnished to		To: rfc-info@RFC-EDITOR.ORG
	others, and derivative works that comment on or otherwise explain it		Subject: getting rfcs
	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		help: ways_to_get_rfcs
	revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		Requests for special distribution should be addressed to either the
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		specifically noted otherwise on the RFC itself, all RFCs are for
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		unlimited distribution.echo
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		Submissions for Requests for Comments should be sent to
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."		RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 13 change blocks.
	234 lines changed or deleted		39 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/