SLP Attrlist: Attribute List Extension for the Service Location Protocol
An optional SLPv2 extension that lets a service reply carry the service's attributes, saving round trips.
Guttman, E., "Attribute List Extension for the Service Location Protocol", RFC 3059, DOI 10.17487/RFC3059, February 2001, <https://www.rfc-editor.org/info/rfc3059>.
@misc{rfc3059,
series = {Request for Comments},
number = 3059,
howpublished = {RFC 3059},
publisher = {RFC Editor},
doi = {10.17487/RFC3059},
url = {https://www.rfc-editor.org/info/rfc3059},
author = {E. Guttman},
title = {{Attribute List Extension for the Service Location Protocol}},
pagetotal = 6,
year = 2001,
month = feb,
} RFC text
Contents
Network Working Group E. Guttman
Request for Comments: 3059 Sun Microsystems
Category: Standards Track February 2001
Attribute List Extension for the Service Location Protocol
Status of this Memo
This document specifies an Internet standards track protocol for 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.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
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.
Table of Contents
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 6
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 UA 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 Attrlist extension, it will
simply return a Service Reply (without the extension). Support of
this extension is OPTIONAL. Existing implementations will ignore the
Attrlist extension since it has been assigned a identifying number
from the range which indicates that the receiver MUST ignore the
extension if it is not recognized. See RFC 2608 [3].
If the UA receives a Service Reply message without an Attrlist
Extension it must assume the SA or DA does not support the extension.
In this case, the UA must send an Attribute Request for each URL it
obtains in the Service Reply message in order to obtain the
attributes for these services.
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 authentication block(s) is exactly the same as would be
included in an Attribute Reply or Service Registration message.
3. IANA Considerations
IANA has assigned an extension ID number of 0x0002 for the Attribute
List Extension.
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] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[4] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
service: Schemes", RFC 2609, June 1999.
[5] Narten, T and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001.
Author's Address
Erik Guttman
Sun Microsystems
Eichhoelzelstr. 7
74915 Waibstadt
Germany
Phone: +49 6227 356 202
EMail: Erik.Guttman@sun.com
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
§1The Extra Round Trips Problem
The Service Location Protocol, Version 2 (SLPv2, RFC 2608) lets a service be discovered in a single exchange: a User Agent (UA) sends a Service Request and a Directory Agent (DA) or Service Agent (SA) sends back a Service Reply. SLP keeps different classes of information in different messages, so the reply does not include the service's attributes.
To get the attributes, the UA has to send more messages. This RFC defines an extension that lets the UA ask for the attributes to ride along in the Service Reply, which removes the need for those extra round trips.
It is like asking a shop where the toy aisle is, and then having to go back and ask what toys they have. This lets you get both answers in one visit.
§1.1The Agents Involved
Three roles appear in the document. A User Agent works on the user's behalf to establish contact with some service. A Service Agent works on behalf of one or more services to advertise them. A Directory Agent collects service advertisements, and there can only be one DA present per given host.
The UA retrieves service information from the SAs or DAs. The key words MUST, SHOULD, OPTIONAL and so on are used as described in RFC 2119.
The UA is you asking questions, the SA is a shopkeeper describing what is for sale, and the DA is a notice board that collects descriptions from many shops.
§2The Attribute List Extension
The extension has Extension ID = 0x0002 followed by a Next Extension Offset, a Service URL Length and Service URL, an Attribute List Length and Attribute List, a count of attribute authentication blocks (the AttrAuths count) and the blocks themselves if present. The Next Extension Offset is the position of the next extension, measured from the start of the SLP message. A value of 0 means there are no more extensions.
The Service URL identifies which URL Entry in the Service Reply the attributes belong to. The Attribute List field holds the entire attribute list of that service.
It is a small label stuck onto the reply. It says which service it is about and lists everything that service can do.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
EXT-ID | Extension ID | 2 bytes | 0x0002 | Identifies this extension. |
NEXT-OFFSET-1 | Next Extension Offset | 2 bytes | Position of the next extension from the start of the SLP message; the offset continues in the next octet. | |
NEXT-OFFSET-2 | Offset, contd. | 1 byte | Rest of the Next Extension Offset; 0 means no more extensions. | |
URL-LENGTH | Service URL Length | 2 bytes | Length of the Service URL; 0 in a request. | |
PAD | Service URL | 1 byte | Variable length; identifies the URL Entry the attributes belong to. |
§2Asking and Answering
A UA sends an empty Attribute List Extension with its Service Request: the Service URL Length and Attribute List Length are 0 and those two fields are omitted. This asks the SA or DA to include an Attribute List Extension in its Service Reply.
An agent that supports the extension returns one Attribute List Extension for every URL Entry in the Service Reply. The order of the extensions SHOULD match the order of the URL Entries. The attributes must be in the same language as that indicated in the Service Request.
Support is OPTIONAL. An agent that does not support it just returns an ordinary Service Reply. The extension was given an identifying number from the range that tells a receiver it MUST ignore an unrecognized extension, so older implementations are not broken.
You hand over an empty form. A helper who knows the trick fills in one form for each service found. A helper who does not know it just hands back the plain answer.
§3Falling Back When Unsupported
If the UA receives a Service Reply without an Attrlist Extension, it must assume the SA or DA does not support the extension. The UA then has to send an Attribute Request for each URL it obtained in the Service Reply to learn the attributes of those services.
So the extension is purely an optimization. A client that uses it works against any SLPv2 agent, and only gains the saved round trips where the agent supports it.
If the answer comes back without the extra details, you just go and ask for them the old way, one by one.
§4Authentication and Languages
If the Service Request includes an SLP SPI string, the Attribute List Extension MUST include an authentication block. If the SA or DA cannot return an authentication block for that SPI, it MUST NOT return an Attribute List Extension. The blocks have exactly the same format as in an Attribute Reply or Service Registration message.
The RFC says SLPv2 already lets authenticators be returned with attribute lists so that UAs can verify a digital signature over the attributes, and the extension reuses that mechanism. It concludes that the extension is no less secure than SLPv2 without it. Language tagging works the same way: the existing SLPv2 mechanism for explicit language tags is reused.
If you ask for a signed answer, you only get the details if they come with a signature. Otherwise you get nothing extra, never an unsigned guess.