RFC 3224 (rfc3224) - Page 2 of 10
Vendor Extensions for Service Location Protocol, Version 2
Alternative Format: Original Text Document
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