Vendor Extensions for Service Location Protocol, Version 2
RFC 3224

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 07

Network Working Group                                         E. Guttman
Request for Comments: 3224                              Sun Microsystems
Updates: 2608                                               January 2002
Category: Standards Track

       Vendor Extensions for Service Location Protocol, Version 2

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 (2002).  All Rights Reserved.

Abstract

   This document specifies how the features of the Service Location
   Protocol, Version 2 allow for vendor extensibility safely, with no
   possibility of collisions.  The specification introduces a new SLPv2
   extension:  The Vendor Opaque Extension.  While proprietary protocol
   extensions are not encouraged by IETF standards, it is important that
   they not hinder interoperability of compliant implementations when
   they are undertaken.  This document udpates RFC 2608, "The Service
   Location Protocol."

Table of Contents

   1.0   Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
      1.1   Terminology  . . . . . . . . . . . . . . . . . .  . . . .  2
   2.0   Enterprise Numbers . . . . . . . . . . . . . . . . . . . . .  3
   3.0   Naming Authorities . . . . . . . . . . . . . . . . . . . . .  3
   4.0   Vendor Defined Attributes  . . . . . . . . . . . . . . . . .  4
   5.0   Vendor Opaque Extension  . . . . . . . . . . . . . . . . . .  5
      5.1 Vendor Opaque Extension Format  . . . . . . . . . . . . . .  6
      5.2 Example: Acme Extension for UA Authentication . . . . . . .  6
   6.0   Extensions Requiring IETF Action . . . . . . . . . . . . . .  7
   7.0   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  7
   8.0   Security Considerations  . . . . . . . . . . . . . . . . . .  8
   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . .  8
   References . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  9
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 10

Guttman                     Standards Track                     [Page 1]
RFC 3224             Vendor Extensions for Service          January 2002

1.0 Introduction

   The Service Location Protocol, Version 2 [1] defines a number of
   features which are extensible.  This document clarifies exactly which
   mechanisms can be used to that end (Sections 3-5) and which cannot
   (Section 6).  This document updates [1], specifying conventions that
   ensure the protocol extension mechanisms in the SLPv2 specification
   will not possibly have ambiguous interpretations.

   This specification introduces only one new protocol element, the
   Vendor Opaque Extension.  This Extension makes it possible for a
   vendor to extend SLP independently, once the vendor has registered
   itself with IANA and obtained an Enterprise Number.  This is useful
   for vendor-specific applications.

   Vendor extensions to standard protocols come at a cost.

      -  Vendor extensions occur without review from the community.
         They may not make good engineering sense in the context of the
         protocol they extend, and the engineers responsible may
         discover this too late.

      -  Vendor extensions preclude interoperation with compliant but
         non-extended implementations.  There is a real danger of
         incompatibility if different implementations support different
         feature sets.

      -  By extending SLPv2 privately, ubiquitous automatic
         configuration is impossible, which is the primary benefit of a
         standard service discovery framework.

   For these reasons, registration of service templates with IANA is
   strongly encouraged!  This process is easy and has proved to be rapid
   (taking less than 2 weeks in most cases).

1.1 Terminology

   In this document, the key words "MAY", "MUST", "MUST NOT",
   "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
   interpreted as described in [2].

   Service Location Protocol terminology is defined in [1].  IANA
   registration terminology is defined in [5].

Guttman                     Standards Track                     [Page 2]
RFC 3224             Vendor Extensions for Service          January 2002

2.0 Enterprise Number

   Enterprise Numbers are used to distinguish different vendors in IETF
   protocols.  Vendor Extensions to SLPv2 SHOULD use these values to
   avoid any possibility of a name space collision.  Each vendor is
   responsible for ensuring that vendor extensions under their own
   authority are non-conflicting.