Internet DRAFT - draft-guttman-slpv2-attrlist-ext
draft-guttman-slpv2-attrlist-ext
Internet Engineering Task Force Erik Guttman
INTERNET DRAFT Sun Microsystems
11 October 1999
Attribute List Extension for the Service Location Protocol
draft-guttman-slpv2-attrlist-ext-01.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 exchanged 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.
Guttman Expires 11 April 2000 [Page i]
Internet Draft Attribute List Extension for SLPv2 11 October 1999
Contents
Status of This Memo i
Abstract i
1. Introduction 1
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Notation Conventions . . . . . . . . . . . . . . . . . . 2
2. Attribute List Extension 2
3. IANA Considerations 3
4. Internationalization Considerations 3
5. Security Considerations 3
6. Acknowledgments 4
7. 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 exchanged of messages. The UA
sends a Service Request message and the DA or SA (as is 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.
Guttman Expires 11 April 2000 [Page 1]
Internet Draft Attribute List Extension for SLPv2 11 October 1999
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 = TBD | 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 TBD, and will be assigned from the 0x0002-0x3fff
range (Standardized options which are optional to implement.)
The Next Extension Offset value is the number of bytes till the next
offset in the SLPv2 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 set to 0 and the Service
URL and Attribute List fields omitted in this case. The UA thereby
Guttman Expires 11 April 2000 [Page 2]
Internet Draft Attribute List Extension for SLPv2 11 October 1999
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
This extension will have to have a unique SLPv2 extension number
assigned. According to RFC 2608:
New SLP Extensions with types in the range 2-65535 may be
registered following review by a Designated Expert [5].
4. Internationalization Considerations
The Service Location Protocol, version 2 has mechanisms for allowing
attribute 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.
Guttman Expires 11 April 2000 [Page 3]
Internet Draft Attribute List Extension for SLPv2 11 October 1999
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: Schemes. RFC 2609, June 1999
[5] T. Narten, H. Alvestrand. Guidelines for Writing an IANA
Considerations Section in RFCs. RFC 2434, October 1998.
[6] H. Alvestrand. Tags for the Identification of Languages. RFC
1766, March 1995.
Author's Address
Erik Guttman
Sun Microsystems
Eichhoelzelstr. 7
74915 Waibstadt
Germany
Phone: +49 7263 911 701
Email: Erik.Guttman@sun.com
Guttman Expires 11 April 2000 [Page 4]
Internet Draft Attribute List Extension for SLPv2 11 October 1999
7. Full Copyright Statement
Copyright (C) The Internet Society (1999). 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."
Guttman Expires 11 April 2000 [Page 5]
