Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Vendor Extensions for Service Location Protocol, Version 2 (RFC3224)

IP.com Disclosure Number: IPCOM000006598D
Original Publication Date: 2002-Jan-01
Included in the Prior Art Database: 2002-Jan-16
Document File: 11 page(s) / 20K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

E. Guttman: AUTHOR

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."

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 18% of the total text.

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...