Internet Engineering Task Force                             Erik Guttman
INTERNET DRAFT                                          Sun Microsystems
16 October 2000
ExpiresA new Request for Comments is now available in six months online RFC libraries.

        RFC 3059

        Title:      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
        Author(s):  E. Guttman
        Status:     Standards Track
        Date:       February 2001
        Mailbox:    Erik.Guttman@sun.com
        Pages:      6
        Characters: 11208
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-guttman-svrloc-attrlist-ext-05.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3059.txt

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

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. now a Proposed Standard Protocol.

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 an Internet standards track protocol for multiple round trip
   messages
the Internet community, and requests discussion and suggestions
for a UA improvements.  Please refer to acquire all service information.

   If the DA or SA does not support the SLPv2 extension, it will simply
   return a Service Reply.  Support current edition 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
"Internet Official Protocol Standards" (STD 1) for 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",
standardization state and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119  [2].

2. Attribute List Extension

   The format status 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        /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |# this protocol.  Distribution
of AttrAuths |(if present) Attribute Authentication Blocks.../
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Extension ID this memo 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 unlimited.

This announcement 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 sent 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 IETF list of and the service.
   These attributes must RFC-DIST list.
Requests to 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 added 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 deleted from the same as would IETF distribution list
should be included in an Attribute Reply or Service Registration message.

3. IANA Considerations

   According sent 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 IETF-REQUEST@IETF.ORG.  Requests 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
added 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 or deleted 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

7. Full Copyright Statement

      Copyright (C) The Internet Society (1999).  All Rights Reserved.

      This document and translations of it may RFC-DIST distribution list should
be copied and furnished sent to
      others, and derivative works that comment RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP 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 EMAIL may not be modified in any way, such as obtained by
      removing the copyright notice or references sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the Internet Society
      or other Internet organizations, except as needed message body
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the purpose
author of developing Internet standards in which case the procedures
      for copyrights defined RFC in the Internet Standards process must be
      followed, question, or as required to translate it into languages other than
      English.

      The limited permissions granted above RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are perpetual and will not for
unlimited distribution.echo
Submissions for Requests for Comments should 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." sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.