Vendor Extensions for Service Location Protocol, Version 2
RFC 3224
Document | Type |
RFC - Proposed Standard
(January 2002; Errata)
Updates RFC 2608
Was draft-guttman-svrloc-vendor-ext (individual)
|
|
---|---|---|---|
Author | Erik Guttman | ||
Last updated | 2013-03-02 | ||
Stream | Legacy stream | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 3224 (Proposed Standard) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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.Show full document text