As per Relevance of the word extension, we have this rfc below:
Network Working Group E.
Request for Comments: 3224 Sun
Updates: 2608 January 2002
Category: Standards
Vendor Extensions for Service Location Protocol, Version 2
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document specifies how the features of the Service
Protocol, Version 2 allow for vendor extensibility safely, with
possibility of collisions. The specification introduces a new SLPv
extension: The Vendor Opaque Extension. While proprietary
extensions are not encouraged by IETF standards, it is important
they not hinder interoperability of compliant implementations
they are undertaken. This document udpates RFC 2608, "The
Location Protocol."
Table of
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
The Service Location Protocol, Version 2 [1] defines a number
features which are extensible. This document clarifies exactly
mechanisms can be used to that end (Sections 3-5) and which
(Section 6). This document updates [1], specifying conventions
ensure the protocol extension mechanisms in the SLPv2
will not possibly have ambiguous interpretations
This specification introduces only one new protocol element,
Vendor Opaque Extension. This Extension makes it possible for
vendor to extend SLP independently, once the vendor has
itself with IANA and obtained an Enterprise Number. This is
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
protocol they extend, and the engineers responsible
discover this too late
- Vendor extensions preclude interoperation with compliant
non-extended implementations. There is a real danger
incompatibility if different implementations support
feature sets
- By extending SLPv2 privately, ubiquitous
configuration is impossible, which is the primary benefit of
standard service discovery framework
For these reasons, registration of service templates with IANA
strongly encouraged! This process is easy and has proved to be
(taking less than 2 weeks in most cases).
1.1
In this document, the key words "MAY", "MUST", "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to
interpreted as described in [2].
Service Location Protocol terminology is defined in [1].
registration terminology is defined in [5].
Guttman Standards Track [Page 2]
RFC 3224 Vendor Extensions for Service January 2002
2.0 Enterprise
Enterprise Numbers are used to distinguish different vendors in
protocols. Vendor Extensions to SLPv2 SHOULD use these values
avoid any possibility of a name space collision. Each vendor
responsible for ensuring that vendor extensions under their
authority are non-conflicting
IANA maintains a repository of all 'SMI Network Management
Enterprise Codes,' whose prefix
iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). The
which follows is unique and may be registered by an on-line form [3].
The complete up-to-date list of Enterprise Numbers is maintained
IANA [3].
3.0 Naming
Naming Authorities are defined by SLPv2 [1] as an agency or
which catalogues Service Types and attributes
A Service Type is a string representing a service which can
discovered by SLPv2. Attributes may be associated with a
Service Type which is advertised by SLPv2.
Service Type strings and service attributes may be registered
IANA by creating a Service Template [4]. The template is included
an internet draft and an email message is sent to srvloc
list@iana.org requesting that the template be included in the
Template registry. In this case, the naming authority for
service type is IANA
It is also possible for a Vendor to create their own
authority. In this case, any service type or attribute may be used
SLPv2 allows arbitrary naming authorities to coexist. To use
explicit naming authority, a vendor simply employs their
Number as a naming authority. For example, for the
(fictitious) Enterprise
9999 Acme, Inc. Erik Guttman femur@example.
the Naming Authority string to use would be "9999". A service:
which used this Naming Authority to advertise a Roadrunner
service could look
service:roadrunner-detector.9999://example.com:9341
Guttman Standards Track [Page 3]
RFC 3224 Vendor Extensions for Service January 2002
Service types which are defined under a naming authority based on
Enterprise Number are guaranteed not to conflict with other
type strings which mean something entirely different. That is
true of attributes defined for service types defined under a
authority
To create a safe naming authority with no possibility of
collisions, a vendor SHOULD use their Enterprise Number as a
authority
4.0 Vendor Defined
SLPv2 [1] suggests
Non-standard attribute names SHOULD begin with "x-", because
standard attribute name will ever have those initial characters
It is possible that two non-standard attributes will conflict
both use the "x-" prefix notation. For that reason, vendors
use "x-" followed by their Enterprise Number followed by a "-"
guarantee that the non-standard attribute name's interpretation
not ambiguous
For example, Acme, Inc.'s Enterprise Number is 9999. Say the
Template for NetHive (a fictitious game) was
------------------------------------------------------------
template-type=
template-version=1.0
template-description
The popular NetHive game
template-url-syntax
url-path = ; There is no path for a NetHive service URL
features= string M
# The list of optional features the NetHive server supports
secure session, fast
current-users= string
# The list of users currently
------------------------------------------------------------
Acme's server advertises a feature which is not on the list
standard features, "x-9999-cheat-mode". Only an Acme client
request this attribute to discover servers, since it is not standard
Guttman Standards Track [Page 4]
RFC 3224 Vendor Extensions for Service January 2002
5.0 Vendor Opaque
SLPv2 [1] defines a protocol extensibility mechanism. SLPv
Extensions are added at the end of a message and have the
format
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 | Next Extension Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset, contd.| Extension Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Extension Data depends on the Extension ID.
to [4] for a full description of different mechanisms available
registration of values with IANA
SLPv2 may be extended in any of three ways
(1) Anyone may request the designated expert for SLP to register
new extension ID with IANA. Send requests to
svrloc-list@iana.org
It is recommended that an internet draft specifying
extension be published, with the intention of publishing
document as an Informational RFC. This way others can use
extension as well. This is not a 'vendor extension' -
this is the preferred way of extending the protocol in a
neutral manner
If no specification is published and the extension is
for vendor specific use only - the 'Vendor Extension'
below probably makes more sense than assigning an extension ID
(2) An experimental extension may be done using the range 0x8000
0x8FFF. There is always the risk, however, that another
will use the same ID, since these IDs are not registered
(3) A Vendor Extension may be used. This extension allows a
to define their own extensions which are guaranteed to have
unique interpretation. It is OPTIONAL to implement
Guttman Standards Track [Page 5]
RFC 3224 Vendor Extensions for Service January 2002
5.1. Vendor Opaque Extension
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 = 0x0003 | Next Extension Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset, contd.| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent. #, contd.| Extension Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Enterprise Number is included in the Extension as a 4
unsigned integer value. The Extension Data following is
to have an unambiguous interpretation determined by the vendor
5.2 Example: Acme Extension for UA
The Acme Corporation, whose Enterprise Number is 9999, can define
extension to SLP. In this example, Acme creates one such
to create an application level access control to service information
This would allow replies to be sent only to clients who
authenticate themselves
The engineers at Acme give the Extension Data the following form
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ACME Ext ID = 1| Client ID Length | Client ID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACME Ext ID: The ACME engineers decided to define the first byte
their extension data as an extension ID field. In the future,
may decide to define more than this extension. Since there is 8
in the ID field, ACME can define up to 256 different extensions.
ACME were to omit this field and begin directly with their '
for UA Authentication', they would only be able to define one
specific SLP extension. For the 'Extension for UA Authentication,'
the ACME Extension ID is set to 1. This ID has to be managed
ACME, to make sure that each new extension they invent has a
ID assigned to it
Guttman Standards Track [Page 6]
RFC 3224 Vendor Extensions for Service January 2002
Client ID Length: This declares how many bytes of Client ID
follow
Client ID: The Acme application user ID
Timestamp: # of seconds since January 1, 2000, 0:00 GMT
Authenticator: a 16 byte MD5 digest [6] calculated on the
data fields, concatenated
- UA request bytes, including the header, but not any extensions
- UA SECRET PASS
- Acme UA Authentication Extension - Client
- Acme UA Authentication Extension -
The SA or DA which receives this extension and supports
extension will check if it (1) recognizes the Client ID, (2) has
associated SECRET PASS PHRASE for it, (3) whether upon calculating
MD5 digest over the same data as listed above it arrives at the
Authenticator value as included in the extension. If all 3 of
steps succeed, the UA has been authenticated
Note this example is for explanatory purposes only. It would
work well in practice. It requires a shared secret be configured
SAs and DAs, for every UA. Furthermore, the UA secret pass
would be susceptible to a dictionary attack
6.0 Extensions Requiring IETF
Modification or extension of any feature of SLPv2 whatsoever,
from those listed in Sections 3-5 of this document, requires
standards action as defined in [1].
Terminology and procedures for IETF Actions related to
of IDs with IANA are defined in [5]. Existing SLPv2
assignments are registered with IANA [3].
7.0 IANA
This document clarifies procedures described in other documents [1]
[4]. The Vendor Opaque Extension ID has already been registered [3].
No additional IANA action is required for publication of
document
Guttman Standards Track [Page 7]
RFC 3224 Vendor Extensions for Service January 2002
8.0 Security
Vendor extensions may introduce additional security
into SLP
This memo describes mechanisms which are standardized elsewhere [1]
[4]. The only protocol mechanism described in this document (
Section 5 above) is no less secure than 'private use'
defined in SLPv2 [1].
The example in Section 5.2 above shows how Vendor Opaque
can be used to include an access control mechanism to SLP so that
can enforce an access control policy using an
mechanism. This is merely an example and protocol details
intentionally not provided. A vendor could, however, create
mechanism similar to this one and provide additional
services to SLPv2 in the manner indicated in the example
I thank the IESG, for their usual persistence and attention
detail
[1] Guttman, E., Perkins, C., Veizades, J. and M. Day, "
Location Protocol, Version 2", RFC 2608, July 1999.
[2] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[3] http://www.iana.org/numbers.
[4] Guttman, E., Perkins, C. and J. Kempf, "Service Templates
URLs", RFC 2609, July 1999.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Considerations Section in RFCs", BCP 26, RFC 2434,
1998.
[6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1992.
Guttman Standards Track [Page 8]
RFC 3224 Vendor Extensions for Service January 2002
Author's
Erik
Sun
Eichhoelzelstr. 7
74915
Phone: +49 7263 911 701
Messages: +49 6221 356 202
EMail: erik.guttman@sun.
Guttman Standards Track [Page 9]
RFC 3224 Vendor Extensions for Service January 2002
Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Guttman Standards Track [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
