Attribute List Extension for the Service Location Protocol
RFC 3059

Document Type RFC - Proposed Standard (February 2001; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 3059 (Proposed Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
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

Guttman                     Standards Track                     [Page 1]
RFC 3059           Attribute List Extension for SLPv2      February 2001

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.

Guttman                     Standards Track                     [Page 2]
RFC 3059           Attribute List Extension for SLPv2      February 2001

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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Show full document text