SLP version compatibility

When SLPv2 advanced to Proposed Standard it included a list of changes made to SLPv1. In certain cases these changes introduced backward compatibility issues which required version-compatibility correction code.

SLPv2bis includes changes to the SLPv2. These changes do not (yet) include new data sent in SLPv2 messages. Rather, certain messages are no longer supported, certain interpretations of message fields have changed. The changes with respect to previous versions have to be presented in the upcoming specification - completely and clearly.

Our goal is to introduce as few incompatibilites as possible - ideally none. If the SLPv2 wire protocol changes, we will have to issue SLPv3 instead of revising SLPv2 and advancing to Draft Standard. So - we aim at full protocol compatibility with existing SLPv2 implementations, even if these agents may not get to use some of their RFC 2608 features in the brave new world.

The point where incompatible features are added is marked in red. Topics for discussion are indicated in blue.

SLP Version Incompatibility Matrix

# Incompatibility SLPv1 (RFC 2165) SLPv2 (RFC 2608) SLPv2bis (as discussed)
01 Unscoped SLPv1 requests Agents treat unscoped requests as matching all scopes. Treat unscoped requests as having 'DEFAULT' scope.
Reconfigure SLPv1 UAs if possible.
As RFC 2608.
02 Unscoped SLPv1 DAs Accept registrations of all scopes. SLPv2 DAs accept only registrations with >0 DA scopes.
Reconfigure SLP1 UAs if possible.
As RFC 2608.
03 Language Tag Length Tags may be 2 characters in length only. 2 or more characters.
If >2 characters, these language tags will make service registrations inaccessible to SLPv1 UAs.
As RFC 2608.
04 Service Types Service types may only be 'concrete.' Abstract types are also allowed.
Do not return abstract service types in SrvTypeRply messages to SLPv1 UAs.
As RFC 2608.
05 Message Header SLPv1 header SLPv2 header. This header is not compatible with SLPv1. SLPv2 header as RFC 2608.
05.1 Monolingual bit If not set, complicated rules apply toward ignoring language tag matching for queries. No Monolingual Bit exists in SLPv2. As RFC 2608.
05.2 Character Encoding Character encoding is explicit in the header. SLPv2 supports the UTF-8 character encoding, only. As RFC 2608.
05.3 URL authenticator flag Indicates a URL entry authentication block follows. This flag is not supported. URL entries may contain 0 or more authentication blocks. As RFC 2608.
05.4 Attribute authenticator flag Indicates an attribute authentication block follows. This flag is not supported. 0 or more authentication blocks may follow attribute lists. As RFC 2608.
05.5 Dialect field Reserved - set to 0. SLPv2 has no dialect field. As RFC 2608.
05.6 Multicast Flag This flag is not present in SLPv1. This flag indicates different rules to follow in case of an error or zero results (drop the message). As RFC 2608.
05.7 Fresh Flag When this flag is present in a SrvAck, the DA informs the UA that the SrvReg is new, not overwriting an existing entry. When this flag is present in a SrvReg, this registration overwrites any existing registration with the same URL. When this flag is absent, a SrvReg will incrementally add to an existing registration. As RFC 2608, except that the Fresh Flag MUST be set on registrations.

If not, return a FRESH_MUST_BE_SET error?
05.8 XID XIDs in requests are copied into XID fields of replies. The XID may take any value.

XIDs in unsolicited DAAdverts are used to indicate DA reboot state.
XIDs in requests are copied into XID fields of replies. The XID may take any non-zero value.

XID is set to zero for unsolicited DAAdverts. Otherwise XIDs are nonzero.
As RFC 2608.
06 Message formats SLPv1 defines formats for messages. This concerns the framing of messages - which fields occur in which order.

Field content changes are described separately below.
SLPv2 redefines all message formats. As RFC 2608.
07 Error Codes SLPv1 defines several error codes:

0 No Error
SLPv2 adds more error codes:


As RFC 2608.

1) MSG_NOT_SUPPORTED returned when dropped features arrive in requests. This will confuse but not break RFC 2608 agents.

2) Define new error codes. RFC 2608 agents will not know what to do, but SLPv2 bis agents will. Examples:

08 Authentication Blocks Algorithms are defined to calculate authentication blocks. SLPv2 redefines all authentication block calculation algorithms. As RFC 2608.
09 Search Filters SLPv1 defines a search filter format, combining service type, scope and search filter.

SLPv1 defines its own search filter syntax.
SLPv2 redefines the search filter format. Service type, naming authority, scope and search filters are separate.

LDAPv3 search filters are used.
As RFC 2608.
10 Scope as attribute SLPv1 defines scope as an attribute of a service. SLPv2 defines scope separately, as a modifier to SLPv2 messages. As RFC 2608.
11 Reserved Strings SLPv1 reserves several strings: SCOPE, SERVICE, IANA, LOCAL, REMOTE, TRUE, FALSE. SLPv2 does not reserve any strings. As RFC 2608.
12 Required Messages All messages are required. UA: Send SrvRqst. Accept SrvRply and DAAdvert.

SA: Send SrvRqst, SrvRply and SrvReg, Accept SrvRqst, DAAdvert and SrvAck.
As RFC 2608.
13 Authentication Use Protected Scope configuration. Use SLP SPIs - an explicit field in protocol messages. These may or may not be tied to scope names. As RFC 2608.
14 Multicast Group Use different global scope groups, including optional (but never implemented) groups arising through hashing of service type strings. Use only one admin scope relative address, except for SLPv2 for IPv6 (RFC 3111). As RFC 2608.
15 SLP Extensions Extensions are not supported. Extensions are supported. As RFC 2608.
16 Wildcards in attrlists Attribute requests allow wildcards in the 'tag list' in the query. As RFC 2165. rev-2608-5
Wildcard are not allowed in the attribute lists.
17 SrvDereg tag list wildcards This support is not in RFC 2165 This support added in RFC 2608. rev-2608-6
Wildcards in tag lists in SrvDereg is not allowed.
18 AttrRqst by type AttrRqst allowed by service type (as opposed to by service URL) As RFC 2165. rev-2608-7
AttrRqst not allowed by type, only by service URL.
19 Scope config rules Priority order is given, not clear. A new list is given. RFC 2610 'MANDATORY' bit is not clear. rev-2608-9
A new clarified configuration priority is list is defined.
20 Elide spaces Initial and final spaces in strings are elided in all protocol fields.

Note: spaces MUST NOT be present, but the protocol MUST be resilient to these errors.
As RFC 2165. rev-2608-10
All strings are matched as is. Initial and final strings will cause strings to fail to match.

As additional revisions are accepted, more table entries will be added. Revisions under discussion are not present in the table.

A text version of this table will be present in the RFC 2608bis specification. Another option would be to include this text in an Applicability Statement (see RFC 2026) which will accompany SLP to draft standard. This latter approach has various advantages. First, we can group SLPv2 and the DHC option together and advance them simultaneously. Second, we can move all text describing the domain of applicability of SLPv2 to this document and thereby separate all discussion of this from the protocol specification. Third, we can unburden the protocol specifications with length compatibility discussions and keep it simple and clean.

Project - Advance SLP to Draft Standard - Top

Erik Guttman, 2001

Source Forge  Logo