RFC 2165
Service Location Protocol
RFC 2165: Service Location Protocol 🎀
okay bestie, let's get the vibes straight first 💅 this is RFC 2165, and it's titled Service Location Protocol ✨
- Written by: J. Veizades (@Home Network), E. Guttman, C. Perkins, and S. Kaplan (Sun Microsystems) 🫶
- Category: Standards Track 🔥
- Date: June 1997 🌸
- Obsoletes / Updates: the header doesn't list any RFCs being obsoleted or updated 🙈
Status of This Memo 🧚
so this doc is an Internet standards track protocol spec for the Internet community, and it's basically asking everyone to talk about it and suggest fixes 💖 if you want to know where it sits in the official standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 and yes, anyone can distribute it, no limits 🌈
Abstract ✨
the Service Location Protocol gives you a scalable way to discover and pick network services 🦋 with it, computers on the Internet don't need nearly as much hand-typed static config for their network apps anymore 💅 this matters SO much now that computers are way more portable and people aren't really into (or able to handle) doing network sysadmin stuff 😭
Table of Contents 🌸
1. Introduction 3
2. Terminology 3
2.1. Notation Conventions . . . . . . . . . . . . . . . . . . 5
2.2. Service Information and Predicate Representation . . . . 5
2.3. Specification Language . . . . . . . . . . . . . . . . . 6
3. Protocol Overview 6
3.1. Protocol Transactions . . . . . . . . . . . . . . . . . . 7
3.2. Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. The "service:" URL scheme . . . . . . . . . . . . 9
3.3. Standard Attribute Definitions . . . . . . . . . . . . . 9
3.4. Naming Authority . . . . . . . . . . . . . . . . . . . . 10
3.5. Interpretation of Service Location Replies . . . . . . . 10
3.6. Use of TCP, UDP and Multicast in Service Location . . . . 10
3.6.1. Multicast vs. Broadcast . . . . . . . . . . . . 11
3.6.2. Service-Specific Multicast Address . . . . . . . 11
3.7. Service Location Scaling, and Multicast Operating Modes . 12
4. Service Location General Message Format 14
4.1. Use of Transaction IDs (XIDs) . . . . . . . . . . . . . . 15
4.2. URL Entries . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Authentication Blocks . . . . . . . . . . . . . . . . . . 17
4.4. URL Entry Lifetime . . . . . . . . . . . . . . . . . . . 19
5. Service Request Message Format 19
5.1. Service Request Usage . . . . . . . . . . . . . . . . . . 22
5.2. Directory Agent Discovery Request . . . . . . . . . . . . 23
5.3. Explanation of Terms of Predicate Grammar . . . . . . . . 24
5.4. Service Request Predicate Grammar . . . . . . . . . . . . 26
5.5. String Matching for Requests . . . . . . . . . . . . . . 27
6. Service Reply Message Format 28
7. Service Type Request Message Format 29
8. Service Type Reply Message Format 31
9. Service Registration Message Format 32
10. Service Acknowledgement Message Format 35
11. Service Deregister Message Format 37
12. Attribute Request Message Format 38
13. Attribute Reply Message Format 40
14. Directory Agent Advertisement Message Format 42
15. Directory Agents 43
15.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 43
15.2. Finding Directory Agents . . . . . . . . . . . . . . . . 43
16. Scope Discovery and Use 45
16.1. Protected Scopes . . . . . . . . . . . . . . . . . . . . 46
17. Language and Character Encoding Issues 47
17.1. Character Encoding and String Issues . . . . . . . . . . 48
17.1.1. Substitution of Character Escape Sequences . . . 49
17.2. Language-Independent Strings . . . . . . . . . . . . . . 49
18. Service Location Transactions 50
18.1. Service Location Connections . . . . . . . . . . . . . . 50
18.2. No Synchronous Assumption . . . . . . . . . . . . . . . . 51
18.3. Idempotency . . . . . . . . . . . . . . . . . . . . . . . 51
19. Security Considerations 51
20. String Formats used with Service Location Messages 52
20.1. Previous Responders' Address Specification . . . . . . . 53
20.2. Formal Definition of the "service:" Scheme . . . . . . . 53
20.2.1. Service Type String . . . . . . . . . . . . . . . 54
20.3. Attribute Information . . . . . . . . . . . . . . . . . . 54
20.4. Address Specification in Service Location . . . . . . . . 55
20.5. Attribute Value encoding rules . . . . . . . . . . . . . 55
21. Protocol Requirements 56
21.1. User Agent Requirements . . . . . . . . . . . . . . . . . 56
21.2. Service Agent Requirements . . . . . . . . . . . . . . . 58
21.3. Directory Agent Requirements . . . . . . . . . . . . . . 59
22. Configurable Parameters and Default Values 61
22.1. Service Agent: Use Predefined Directory Agent(s) . . . . 62
22.2. Time Out Intervals . . . . . . . . . . . . . . . . . . . 63
23. Non-configurable Parameters 63
24. Acknowledgments 64
A. Appendix: Technical contents of ISO 639:1988 (E/F): "Code for
the representation of names of languages" 65
B. SLP Certificates 66
C. Example of deploying SLP security using MD5 and RSA 68
D. Example of use of SLP Certificates by mobile nodes 68
E. Appendix: For Further Reading 691. Introduction 🦋
okay so traditionally, users find services by typing in the name of a network host (a human-readable string that's basically an alias for a network address) 🫠 SLP is like, "nah, you don't need to know the host name at all" 💅 instead, the user just names the service and gives a set of attributes that describe it, and SLP lets them tie that description to the service's actual network address ✨ main character energy for sure 👑
SLP is a dynamic configuration mechanism for apps on local area networks 🌈 it is NOT a global resolution system for the whole Internet, bestie 🙈 it's meant for enterprise networks with shared services. Clients are modeled as needing to find servers that live on the enterprise network, maybe somewhere kinda far away 🧚 when there are tons of clients and/or services, the protocol can use nearby Directory Agents, which act as a centralized repository for advertised services 🫶
2. Terminology 💜
here's the glossary, babe, so we're all speaking the same language 📚
- User Agent (UA): a process working on the user's behalf to grab service attributes and configuration 🎀 it pulls service info from Service Agents or Directory Agents.
- Service Agent (SA): a process working on behalf of one or more services to advertise their attributes and configuration 🌸
- Service Information: a collection of attributes and configuration info tied to a single service 🧁 Service Agents advertise service info for a whole bunch of service instances.
- Service: a process or system that provides a facility to the network 🔥 you access the service itself through a communication mechanism that is outside SLP, so SLP isn't the thing doing the actual talking 💅
- Directory Agent (DA): a process that collects info from Service Agents into a single repository, so User Agents can access it efficiently 🌈 there can only be one DA per given host, no exceptions 🙅♀️
- Service Type: every type of service has its own unique Service Type string 💖 the Service Type defines a template (called a "service scheme") that includes the expected attributes, values, and protocol behavior 🦋
- Naming Authority: the agency or group that catalogues given Service Types and Attributes ✨ the default Naming Authority is IANA, the Internet Assigned Numbers Authority 👑
- Keyword: a string describing a characteristic of a service 🍓
- Attribute: a (class, value-list) pair of strings describing a characteristic of a service 💜 the value string can be read as a boolean, an integer, or an opaque value if it takes specific forms (see section 20.5) 🧚
- Predicate: a boolean expression made of attributes, relations, and logical operators 🔥 it's used to find services that meet particular requirements. See section 5.3 💅
- Alphanumeric: a character within the range
'a'to'z','A'to'Z', or 🙈 (the definition in the original ends right there, so that's where we leave it too) - Scope: a collection of services that make up a logical group 🌸 see sections 3.7 and 16 ✨
- Site Network: all the hosts you can reach within the Agent's multicast radius 🦋 that radius defaults to a value that's appropriate for reaching all hosts within a site (see section 22). If the site doesn't support multicast, the agent's site network is restricted to a single subnet 🫶
- URL: a Universal Resource Locator, see [6] 🎀
- Address Specification: the network-layer-protocol-dependent mechanism for specifying an Agent 💖 for Internet systems, this is part of a URL 🌈
2.1. Notation Conventions 🌸
okay now the notation, which is how you read the rest of the doc without getting lost 📖
- CAPS: strings written in all capital letters are protocol literals 🔥 all string comparison is case insensitive, though (see section 5.5) 💅 some strings are quoted in this document to show they should be used literally, and single characters inside apostrophes are included literally 🧚
<>: values set off in angle brackets are fully described in section 20 🦋 in general, every definition of an item in messages is described in section 20 or right after its first use ✨| |and\ \: message layouts with this notation show a variable-length field 🌈 here's how it looks:
| |
\ \ Message layouts with this notation indicate a variable
| | length field.2.2. Service Information and Predicate Representation 📝
okay so service info is written in a text format, and the whole point is that it's human readable AND can be sent over email 💌 you could literally paste it into a message to your bestie 🫶 Service locations are written as a Universal Resource Locator (URL), which is also human readable 🔗 Only the datagram headers are in a form that isn't human readable 🤖 And strings in the Service Location Protocol are NOT null-terminated 💀 not me being shook by that one 😭
Predicates are written in a simple boolean notation using keywords, attributes, and logical connectives, as described in Section 5.4 🧠✨
The logical connectives and subexpressions are written in prefix-order, so the connective comes FIRST and then the expressions it operates on follow after 🧁 the way that it's giving main character energy 👑
2.3. Specification Language 🔠
In this document, a few words are used to signal the requirements of the specification [8]. They're often capitalized, so you know they're serious business 👀💅
MUST This word, or the adjective "required", means that
the definition is an absolute requirement of the
specification.
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
SHOULD This word, or the adjective "recommended", means
that, in some circumstances, valid reasons may exist to
ignore this item, but the full implications must be
understood and carefully weighed before choosing a
different course. Unexpected results may result
otherwise.
MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST
be prepared to interoperate with another implementation
which does include the option.
silently discard
The implementation discards the datagram without
further processing, and without indicating an error to
the sender. The implementation SHOULD provide the
capability of logging the error, including the contents
of the discarded datagram, and SHOULD record the event
in a statistics counter.3. Protocol Overview 🧭
the basic move in Service Location is that a client tries to discover where a Service is 🔍 In smaller installations, each service gets configured to respond individually to each client 🏠 In larger installations, services register themselves with one or more Directory Agents, and clients go to the Directory Agent to get their Service Location info 📮 Clients can find out where a Directory Agent is by preconfiguration, DHCP [2, 11], or by sending queries to the Directory Agent Discovery multicast address 🗺️
3.1. Protocol Transactions 📞
the diagram below shows how all of these relationships connect 👇
+---------------+ we want this info: +-----------+
| Application | - - - - - - - - - - - -> | Service |
+---------------+ +-----------+
/|\ | |
| +-------------+ |
| | |
\|/ \|/ \|/
+---------------+ +-----------+ +----------------+
| User Agent |<-------->| Service | | Service |
+---------------+ | Agent | | Agent which |
| +-----------+ | does not reply |
| | | to UA requests |
| \|/ +----------------+
| +-------------+ |
+------------------>| Directory |<----------+
| Agent |
+-------------+ ___________
/|\ / Many other\
+------------>| SA's |
\___________/okay so here's what a User Agent does to find services on the site's network 🕵️♀️✨ The User Agent needs NO configuration to start talking to the network 🙌 It can pick up info to build predicates that describe the services matching what the user needs 🎯 And the User Agent can build on info it got from earlier network requests when it's hunting down the Service Agents that are advertising service info 🧩
A User Agent operates in two ways 💖 If the User Agent has already found a Directory Agent, it unicasts a request to that DA to resolve a particular request, and the Directory Agent unicasts a reply back to the User Agent 📬 The User Agent keeps retrying a request to a Directory Agent until it gets a reply, so if the Directory Agent can't service the request (say it has no info), it must return an response with zero values, possibly with an error code set 🙈
If the User Agent doesn't know about a Directory Agent, or there are no Directory Agents available on the site network, a second mode of discovery can be used 🔄 The User Agent multicasts a request to the service-specific multicast address, which is where the service it wants to find will respond 📣 All the Service Agents listening to this multicast address will respond, as long as they can satisfy the User Agent's request ✅ A similar mechanism is used for Directory Agent discovery; see section 5.2. Service Agents which have no information for the User Agent MUST NOT respond 🤫
When a User Agent wants an enumeration of ALL services that satisfy the query, a retransmission/convergence algorithm is used 🧮 The User Agent resends the request, together with a list of previous responders, and only the Service Agents that aren't on that list respond 🙋♀️ Once there are no new responses to the request, the accumulation of responses is deemed complete 🏁 Depending on the length of the request, around 60 previous responders can be listed in a single datagram. If there are more responders than this, the scaling mechanisms described in section 3.7 should be used 📏
the multicast/convergence model might be important for discovering services (like Directory Agents), but it's the exception rather than the rule 🌈 Once a User Agent knows where a Directory Agent is, it uses a unicast request/response transaction 💜
The Service Agent SHOULD listen for multicast requests on the service-specific multicast address, and MUST register with an available Directory Agent 📝 This Directory Agent resolves requests from User Agents that are unicasted using TCP or UDP 📡 That means a Directory Agent has to be discovered first, using DHCP, the DA Discovery Multicast address, the multicast mechanism described above, or manual configuration. See section 5.2 🔎
a Service Agent that doesn't respond to multicast requests won't be useful when there are no Directory Agents 🙃 Some Service Agents might not include this functionality, if an especially lightweight implementation is required 🪶
If a service is going to become unavailable, it should be deregistered with the Directory Agent 🫥 The Directory Agent responds with an acknowledgment to either a registration or a deregistration 🤝 Service Registrations include a lifetime, and they'll eventually expire ⏳ So Service Agents need to refresh their Service Registrations before their Lifetime runs out 🔁 And if need be, Service Agents can advertise signed URLs to prove they're authorized to provide the service 🔐✨
3.2. Schemes 🔗
the Service Location Protocol is designed as a way for clients to access resources on the network, which makes it a natural fit for Universal Resource Locators (URLs) 💫 By re-using URL specification and technology from the World Wide Web, clients and servers can be more flexible and written using code that already exists 🛠️ It's also hoped that browsers will be written to take advantage of how similar the locator formats are, so a client can dynamically formulate requests for services that get resolved differently depending on the circumstances 🌸
3.2.1. The "service:" URL scheme 🎀
the service URL scheme is used by Service Location, and it's used to specify a Service Location 📍 Lots of Service Types will be named by including a scheme name after the "service:" scheme name. Service Types are used by SAs to register and deregister Services with DAs 📋 They're also used by SAs and DAs to return Service Replies to UAs 💌 The formal definition of the "service:" URL scheme is in section 20.2. The format of the info that follows the "service:" scheme should follow the URL structure and semantics formalized by the IETF standardization process as closely as possible 🧐 Well known Service Types are registered with the IANA, and templates are available as RFCs 📚 Private Service Types may also be supported 🔒
3.3. Standard Attribute Definitions 🏷️
Service Types used with the Service Location Protocol must describe the following:
- Service Type string of the service
- Attributes and Keywords
- Attribute Descriptions and interpretations
Service Types that aren't registered with IANA will use their own Naming Authority string 🪪 The registration process for new Service Types is defined in [13] 📝
Services that advertise a particular Service Type must support the complete set of standardized attributes 💯 They can support additional attributes beyond the standardized set 🌟 Unrecognized attributes MUST be ignored by User Agents 🙅♀️
Service Type names that begin with "x-" are guaranteed not to conflict with any officially registered Service Type names 🧸 It's suggested that this prefix be used for experimental or private Service Type names 🧪 Similarly, attribute names that begin with "x-" are guaranteed not to be used for any officially registered attribute names 🫧
A service of a given Service Type should accept the networking protocol implied in its definition 🔌 If a Service Type can accept multiple protocols, configuration information SHOULD be included in the Service Type attribute information 🛠️ This configuration information lets an application use the results of a Service Request and Attribute Request to connect directly to a service 💞
See section 20.2.1 for the format of a Service Type String as used in the Service Location Protocol 📖
3.4. Naming Authority 🏛️
The Naming Authority of a service defines the meaning of the Service Types and attributes that get registered with and provided by Service Location 🗂️ The Naming Authority is a string that uniquely identifies an organization 🆔 If no string is provided, IANA is the default 🌷 IANA stands for the Internet Assigned Numbers Authority 🦋
Naming Authorities can define Service Types that are experimental, proprietary, or for private use 🧪 The procedure is to create a 'unique' Naming Authority string and then specify the Standard Attribute Definitions as described above 💅 This Naming Authority will accompany registration and queries, as described in sections 5 and 9 ✨
3.5. Interpretation of Service Location Replies ✨
okay so replies are valid when they show up 📬 but ngl a service can totally die or change between the reply and the moment an app actually tries to use it 😭. So the app using Service Location MUST be ready for info that's stale or incomplete 🫶. If the info doesn't let a User Agent connect the way it wants, it's fine to resubmit the Service Request and/or Attribute Request 🔁.
Service specific config stuff (like which protocol to use) should go in as attributes in Service Registrations 🎀. The apps reading the Service Location Reply are the ones that use these config attributes 💅.
3.6. Use of TCP, UDP and Multicast in Service Location 🦋
the Service Location Protocol needs UDP (connectionless) and TCP (connection oriented) transports implemented 🔌. TCP is for bulk transfer, but only when it's actually necessary 📦. Connections are always started by an agent's request or registration, never by a Directory Agent that's replying 🙅♀️. Service Agents and User Agents send their info to the service location port, which is 427, using ephemeral ports 🧚.
Service Location discovery usually multicasts messages to as many enterprise networks as it takes to confirm services are available 🌐. The protocol still works in a broadcast environment, just with limitations, which are detailed in section 3.6.1 💜.
3.6.1. Multicast vs. Broadcast
the Service Location Protocol was designed for networks where DHCP is available or multicast is supported at the network layer 🎀. If only network layer broadcast is supported, the following procedures may be followed 🍓.
3.6.1.1. Single Subnet
if a network isn't connected to any other networks, plain network layer broadcasts work instead of multicast 🌸.
Service Agents SHOULD and Directory Agents MUST listen for broadcast Service Location request messages on the Service Location port 👑. This lets UAs without multicast capability still use Service Location on a single subnet 🫶.
3.6.1.2. Multiple Subnets
the Directory Agent is the central clearing house of info for User Agents 🏠. If a Directory Agent address is statically configured on each User Agent and Service Agent, the Directory Agent acts as a bridge for info living on different subnets 🌉. The DA address can be configured dynamically on Agents using DHCP, or it can be set by static configuration 🔧.
dynamic discovery isn't feasible in a broadcast environment with multiple subnets, and manual config is a pain 😩. So deploying DAs to serve enterprises with multiple subnets will need multicast discovery with multiple hops (i.e., TTL > 1 in the IP header) 🦋.
3.6.2. Service-Specific Multicast Address 💖
this mechanism exists so that the number of datagrams any one service agent receives stays as low as possible 🙈. The Service Location General Multicast Address MAY be used to query for any service, but one SHOULD use the service-specific multicast address if it exists ✨.
If the site network doesn't support multicast, the query SHOULD be broadcast to the Service Location port 📡. If the underlying hardware can't support the number of multicast addresses needed, the Service Location General Multicast Address MAY be used instead 🧩. Service Agents MUST listen on this multicast address as well as on the service-specific multicast addresses for the service types they advertise 👂.
Service-Specific Multicast Addresses are computed by running a string hash on the Service Type string 🔢. The Service Type string MUST first be converted to an ASCII string from whatever character set it's represented in, so the hash gives well-defined results 💅.
The string hash function is modified from a code fragment attributed to Chris Torek 🧚♀️:
/*
* SLPhash returns a hash value in the range 0-1023 for a
* string of single-byte characters, of specified length.
*/
unsigned long SLPhash (const char *pc, unsigned int length)
unsigned long h = 0;
while (length-- != 0) {
h *= 33;
h += *pc++;
}
return (0x3FF & h); /* round to a range of 0-1023 */
}This value gets added to the base range of Service Specific Discovery Addresses, which IANA will assign 🌈. These will be 1024 contiguous multicast addresses 💜.
3.7. Service Location Scaling, and Multicast Operating Modes 🌸
in a very small network with only a few nodes, no DA is needed 🏡. A user agent can detect services by multicasting requests, and Service Agents will reply to them 📣. Service Agents that respond to user requests also have to be used to make service info available 🫶. This doesn't scale to environments with lots of hosts and services 💀.
When you scale Service Location up to intermediate sized networks, a central repository (Directory Agent) can be added to cut down the number of Service Location messages on the network infrastructure ⭐. Since the central repository can respond to all Service and Attribute Requests, fewer Service and Attribute Replies are needed, and for that same reason there's no need to tell Directory Agents apart 🧚.
A site might also grow so big that one central repository isn't feasible anymore 😭. Then more Directory Agents are needed. The services (and service agents) advertised by the several Directory Agents get grouped together into logical groupings called "Scopes" 🎀.
All Service Registrations that have a scope must be registered with all DAs (within the appropriate multicast radius) of that scope that have been or are later discovered 🔍. Service Registrations with no scope are only registered with unscoped DAs 📝. User Agents make requests of DAs whose scope they're configured to use 🦋.
Service Agents MUST register with unscoped DAs even if they're configured to specifically register with DAs that have a particular scope or set of scopes 🙌. User Agents MAY query DAs without scopes, even if they're configured to use DAs with a certain scope 💜. This is because any DA with no scope will have all the available service info 🫶.
Scoped user agents SHOULD always use a DA that supports their configured scope when possible, instead of an unscoped DA 🌈. This keeps the unscoped DAs from getting overused and turning into a scaling problem 💅.
It's possible to specially configure Service Agents to register only with a specific set of DAs (see Section 22.1) 🔧. In that case, services may not be available to User Agents through every Directory Agent, but some network administrators may think that's fine 🤷♀️.
There are thus 3 distinct operating modes 🍓. The first requires no administrative intervention. The second requires only that a DA be run. The last requires that all DAs be configured to have scope and that a coherent strategy of assigning scopes to services be followed 📋. Users must be told which scopes are appropriate for them to use 🎀. This admin effort lets users and applications dynamically discover services later without any help ✨.
The first mode (no DAs) is intended for a LAN 🏠. The second mode (using a DA or DAs, but not using scopes) scales well to a group of interconnected LANs with a limited number of hosts 🌉. The third mode (with DAs and scopes) lets SLP be used in an internetworked campus environment 🏫.
If scoped DAs are used, they won't accept unscoped registrations or requests 🚫. UAs that issue unscoped requests will only discover unscoped services 🙈. They SHOULD use a scope in their requests if possible, and SHOULD use a DA with their scope in preference to an unscoped DA 💖. In a large campus environment it would be a bad idea to have ANY unscoped DAs, because they attract ALL registrations and will eventually present a scaling problem 😭🔥.
4. Service Location General Message Format ✨
okay bestie, every Service Location message starts with the same header 💖 In the message descriptions below, we just write "Service Location header =" followed by the function being used, so you don't have to redraw it every time 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Function | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|M|U|A|F| rsvd| Dialect | Language Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Char Encoding | XID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version is just version 1 of the Service Location protocol, nothing fancy 💅 This document defines it.
Function is how we tell datagrams apart by what they're doing 🦋 These are the defined operations:
Message Type Abbreviation Function Value
Service Request SrvReq 1
Service Reply SrvRply 2
Service Registration SrvReg 3
Service Deregister SrvDereg 4
Service Acknowledge SrvAck 5
Attribute Request AttrRqst 6
Attribute Reply AttrRply 7
DA Advertisement DAAdvert 8
Service Type Request SrvTypeRqst 9
Service Type Reply SrvTypeRply 10Length is the number of bytes in the whole message, including the Service Location Header 📏
O is the 'Overflow' bit 🌸 Check Section 18 to see how it gets used.
M is the 'Monolingual' bit 🌈 When it's set on a request, the User Agent will only accept replies in the language (see section 17) that the Service or Attribute Request indicated. Very particular, very iconic 👑
U is the 'URL Authentication Present' bit 🔐 Sections 4.2, 4.3, 9, and 11 explain how this one is used.
A is the 'Attribute Authentication Present' bit 🔑 Sections 4.2, 4.3, and 13 cover this one.
F is for when it's set in a Service Acknowledgement 💖 It means the directory agent registered the service as a brand-new entry, not an updated one.
rsvd is reserved, so it MUST be zero 🙈 No exceptions, bestie.
Dialect is where future versions of the Service Location Protocol will put tags for a variant of vocabulary 🧚 Right now it's reserved, and it MUST be set to 0 so future versions stay compatible 💜
Language Code tells you how to read the strings in the rest of the message: they're in the language encoded here (see section 17 and appendix A) 🍓
Character Encoding means the characters in those strings can be encoded in any standardized encoding (see section 17.1) ✨
Transaction Identifier (XID) is how the requester matches replies to the right requests 🎀 Check section 4.1 for the deets.
Note that whenever there is an Attribute Authentication block, there will also be a URL Authentication block 🚨 So it's an error to have the 'A' bit set without also having the 'U' bit set. Don't be that person 💀
4.1. Use of Transaction IDs (XIDs)
okay so retransmission is how we keep things reliable in the Service Location Protocol 🔁 If a User Agent or Service Agent sends a message and doesn't get the response it expected, the message gets sent again. The retransmitted datagram should not contain an updated XID 🙈 Why? Because it's totally possible the original request made it to the DA or SA, and only the reply got lost on the way back 😭 Keeping the same XID lets the DA or SA cache its reply to the original request and send that same reply again if a duplicate request shows up. Main character behavior 💅
That cached info should only be held very briefly (CONFIG_INTERVAL_0.) ⏳ And any registration or deregistration at a Directory Agent, or any change of service information at a SA, should flush that cache so the info sent back to the client is always valid 🫶
The requester makes its XIDs from an initial random seed and bumps it by one for every request it makes 🦋 Eventually the XIDs wrap back around to zero and keep counting up from there 🔄
Directory Agents also use XID values in their DA Advertisements to show their state (see section 15.2) 👑
4.2. URL Entries
okay so when URLs get registered, they come with lifetimes and lengths, and they might be authenticated 🔐 All of these values stay attached to the URL for as long as the registration lasts 💖 That whole combo is called a "URL-entry", and it looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Length of URL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ URL \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) URL Authentication Block .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Lifetime is how long the registration stays valid 🕰️ That's assuming nobody registers or deregisters later and changes things up.
Length of URL is the length of the URL in bytes, and it has to be < 32768 📏
URL Authentication Block is optional 🔏 If it's there, it's a timestamped authenticator (section 4.3) 💜
The URL follows RFC 1738 [6] 🌐 If the 'U' bit is set in the message header, the URL gets followed by an URL Authentication Block 🫶 And if the scheme used in the URL doesn't have a standardized representation, the minimum requirement is:
service:<srvtype>://<addr-spec>"service" is the URL scheme for all Service Location Information in service registrations and service replies ✨ Every URL entry carries the service:<srvtype> scheme name 🎀 It can also include an <addr-spec>, except when it's a reply to a Service Type request (see section 7) 🧚
4.3. Authentication Blocks
okay so authentication blocks are how we authenticate service registrations and deregistrations 🔐 URLs get registered along with a URL Authentication block, so the authentication info stays in the URL entry for later use by User Agents who get a Service Reply containing that entry 💖 Service attributes get registered with an Attribute Authentication block instead 🦋 Both blocks have the format shown below.
Here's the key rule 👑 If a service registration comes with authentication the DA can validate, the DA MUST validate any later service deregistrations, so unauthorized entities can't knock out those registered services 🙅♀️ Same deal for attributes: if a service registration comes with an Attribute Authentication block the DA can validate, the DA MUST validate any later attribute registrations, so nobody unauthorized can wipe out registered attributes 💅
To stop replay attacks that reuse previously validated deregistrations 😈, the deregistration or attribute registration message must contain a timestamp for the DA to use. And to stop replay attacks that use previously validated registrations to cancel out a valid deregistration, registrations must contain a timestamp too ⏰
An authentication block looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Structure Descriptor | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Structured Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Timestamp is a 64-bit value formatted the way the Network Time Protocol (NTP) [16] specifies ⏱️
Block Structure Descriptor (BSD) describes how the Authenticator is structured 🧩 The only value defined so far is 1, which means Object-Identifier 🆔
Length is the length of the Authenticator 📏
Structured Authenticator holds an algorithm specification, plus the authentication data that algorithm produced 🔐
The Structured Authenticator contains a digital signature of the info being authenticated ✍️ It has enough info to figure out which algorithm to use, and which keys to pick for verifying that digital signature 🗝️
The digital signature gets computed over this ordered stream of data:
CHARACTER ENCODING OF URL (2 bytes in network byte order)
LIFETIME (2 bytes in network byte order)
LENGTH OF URL (2 bytes in network byte order)
URL (n bytes)
TIMESTAMP (8 bytes in SNTP format [16])When making a URL Authentication block, the authentication data that the algorithm named in the Structured Authenticator produces is calculated over this ordered stream of data:
ATTRIBUTE CHARACTER ENCODING (2 bytes in network byte order)
LENGTH OF ATTRIBUTES (2 bytes in network byte order)
ATTRIBUTES (n bytes)
TIMESTAMP (8 bytes in SNTP format [16])Every Service Location Protocol entity (User Agent, Service Agent, or Directory Agent) that's configured for use with protected scopes SHOULD implement "md5WithRSAEncryption" [4] and be able to associate it with BSD value == 1 🙌
When BSD value == 1 and the OID "md5WithRSAEncryption" gets selected, the Structured Authenticator starts with the ASN.1 Distinguished Encoding (DER) [9] for "md5WithRSAEncryption" 🧁 Its value is these bytes (MSB first in hex):
"30 0d 06 09 2a 86 48 86 f7 0d 01 01 04 05 00"That's immediately followed by an ASN.1 Distinguished Encoding (as a "Bitstring") of the RSA encryption (using the Scope's private key) of a bitstring. That bitstring is the OID for "MD5" concatenated with the MD5 [22] message digest computed over the fields above 🔏 The exact construction of the MD5 OID and digest can be found in RFC 1423 [4] 📚
4.4. URL Entry Lifetime 💅✨
Okay so the Lifetime field is basically the "how long can you keep this for" timer 🕰️. It holds the number of seconds a reply can be cached by any agent. A value of 0 means the info must NOT be cached 🙅♀️. User Agents MAY cache service information, but if they do, they MUST give applications a way to flush that cache and send the request straight onto the network 🫶.
Services should be registered with DAs with a Lifetime, and the suggested value is CONFIG_INTERVAL_1 🎀. The service MUST be reregistered before that interval runs out, or its advertisement stops being available 😭. So if a service vanishes and forgets to deregister, it eventually gets automatically deregistered on its own. Iconic self-cleaning behavior 🧹💖.
5. Service Request Message Format 🌸
The Service Request is how you go grab URLs from a Directory Agent or Service Agents 🔍✨.
Here's what it looks like:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvReq) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|length of prev resp list string|<Previous Responders Addr Spec>|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Previous Responders Addr Spec> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of predicate string | Service Request <predicate> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ Service Request <predicate>, contd. \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+If a UA sends a request whose reply would be too big 📦💀, the SA or DA sends back an abbreviated response (in a datagram the size of the site's MTU) with the 'Overflow' bit flag set 🚩. The UA MUST then issue the request again using TCP 🔁.
The <Previous Responders Addr Spec> is described in sections 7 and 20.1 📖.
After a User Agent restarts (like after a system reboot or loading the network kernel) 🔄, Service Requests SHOULD be delayed for some random time uniformly distributed within a one second interval centered about a configured delay value (by default, CONFIG_INTERVAL_4) ⏳.
The Service Request lets the User Agent specify the Service Type of the service and a Predicate in a specific language 🧠. The general form of a Service Request looks like this:
<srvtype>[.<na>]/[<scope>]/[<where>]/The punctuation is necessary even where the fields are omitted 🙈.
- The <srvtype> is the Service Type 🏷️. Every kind of service has its own unique Service type name string. See section 20.2.1.
- The <na> is the Naming Authority 🏛️. This string decides how the attribute info in the <where> part gets interpreted.
- The <scope> is a string that restricts the range of the query 🗺️. Scope gets decided administratively at a given site, and it isn't necessarily related to network topology (see Section 16). If you leave this field out, the request can only be satisfied by unscoped service advertisements.
- The <where> string is the Where Clause of the request 🔍. It holds a query that picks out the service instances the User Agent cares about. The query includes attributes, boolean operators and relations (See section 5.3).
For a multicast service request, a list of previous responders gets sent along 📬. That list stops the listed folks from responding, so responses from other sources don't get drowned out 🌊. The request gets multicast repeatedly (with a recommended wait interval of CONFIG_INTERVAL_2) until there are no new responses, or until a certain time (CONFIG_INTERVAL_3) has passed ⏱️. Directory Agent Discovery requests use different timing values, see Section 5.2 👀.
For a request to actually match registered info, all of these conditions MUST be met:
- The result MUST have the same Service Type as the request.
- It MUST have the same Naming Authority.
- It MUST have the same scope. (If the scope of the request is omitted, the request will only match services that were registered with no scope. Note that a scoped request WILL match all unscoped Services 🫠.)
- The conditions specified in the Where Clause MUST match the attributes and keywords registered for the service.
5.1. Service Request Usage 🧃
The User Agent MAY form Service Requests using preconfigured knowledge of a Service Type's attributes 📚. It can also issue Attribute Requests to get the attribute values for a Service Type before sending Service Requests (see Section 13) 🔎. Once it has the attributes describing a kind of service, either from an Attribute Request or from configured knowledge, the User Agent can build a predicate that describes what the user needs 💖.
Service Requests MAY be sent directly to a Directory Agent 🎯. Say you need a printer supporting the lpr protocol on the 12th floor 🏢, one that has UNRESTRICTED_ACCESS and prints 12 pages per minute 🖨️. Now say an Attribute Request shows there's a printer on the 12th floor, a printer that prints 12 pages per minute, and a printer that offers UNRESTRICTED_ACCESS. To check whether they're all the same printer, you'd send this:
lpr//(& (PAGES PER MINUTE==12)
(UNRESTRICTED_ACCESS)
(LOCATION==12th FLOOR))/If there's no such printer, the Directory Agent responds with a Service Reply with 0 in the number of responses and no reply values 😢.
The User Agent then tries a less restrictive query to find a printer, using the 12th floor as the "where" criteria 🪄.
lpr//(LOCATION==12th FLOOR)/This time there's only one reply 🎉:
Returned URL: service:lpr://igore.wco.ftp.com:515/draftThe Address Specification for the printer is igore.wco.ftp.com:515, which names the host managing the requested printer 🖥️. Files get printed by spooling to that port on that host. The word 'draft' is the name of the print queue the lpr server supports 📄.
If there's no Directory Agent, the request above could be multicast instead 📡. In that case it gets sent to the Service Specific Multicast Address for "service:printer", not to a Directory Agent. Service Agents that can satisfy the predicate will reply 💌. Service Agents that can't support the character set of the request MUST return CHARSET_NOT_UNDERSTOOD in the SrvRply. In every other situation, Service Agents that can't satisfy the request don't send any reply at all 🤐.
The only way a User Agent can be sure there are no services matching the query is by retrying the request (CONFIG_INTERVAL_8) 🔁. If no response comes, the User Agent gives up and assumes there are no such printers 😔.
There's also a simpler 'join' query 🧩. Its syntax has no parentheses or logical operators, and each term is conjoined (AND-ed together). Here's the original query rewritten as a join:
lpr//PAGES PER MINUTE==12,
UNRESTRICTED_ACCESS,
LOCATION==12th FLOOR/5.2. Directory Agent Discovery Request 🕵️♀️
Normally a Service Request returns a Service Reply. The one exception is a Service Request for the Service Type "directory-agent", which gets answered with a DA Advertisement 🙌.
Without configured knowledge of a Directory Agent (DA), a User Agent or Service Agent uses a Service Request to discover a DA. (See section 15.1 for the mechanisms by which a client may be configured to know about a DA.) A Service Request used for Directory Agent Discovery includes a predicate of this form:
directory-agent///This query is ALWAYS sent to the Directory Agent Discovery multicast address 📢. The Service Type of a Directory Agent is "directory-agent", so that's the Service Type used in the request. No scope is included, so all Directory Agents will reply 🌍. This is the only request that omits a scope, and all Directory Agents MUST respond to it. Normally, a Directory Agent with a scope ONLY responds to requests with that scope. No Naming Authority is included, so "IANA" is assumed 🧐. We want to reach every available directory agent. If a scope were supplied, only DAs supporting that scope would reply.
DA Advertisement Replies may arrive from different sources, looking something like:
URL returned: service:directory-agent://slp-resolver.catch22.com
Scope returned: ACCOUNTING
URL returned: service:directory-agent://204.182.15.66 Scope
returned: JANITORIAL SERVICESThe DA Advertisement format is defined in Section 14 📝.
If you just want to find any Directory Agent, the first reply will do 🥳. If the goal is to discover all reachable DAs, the request MUST be retransmitted after an interval (the recommended time is CONFIG_INTERVAL_5) ⏲️. This retransmitted request includes a list of DAs that have already responded (see sections 7 and 20.1). Directory Agents that receive the request will only respond if they are not on this list. Once there are no new replies, all DAs are presumed to have been discovered 🎊.
If a DA fails to respond after CONFIG_INTERVAL_6 seconds, the UA or Service Agent SHOULD use a different DA 🔄. DA addresses may be cached from previous discovery attempts, preconfigured, or obtained by use of DHCP (see section 15.2). If no such DA responds, DA discovery SHOULD be used to find a new DA 🕵️. Only after CONFIG_INTERVAL_7 seconds should it be assumed that no DA exists, and multicast based Service Requests SHOULD be used instead 📡💜.
5.3. Explanation of Terms of Predicate Grammar ✨
okay so a predicate is giving very structured 💅 it runs on parentheses, commas and slashes to separate all the bits. Proper usage examples are scattered all through this doc. Here are the terms bestie needs to know:
predicate: the thing you put in a Service Request so that a Service Agent or Directory Agent knows what info to send back 🎀
scope: if the scope is missing from a Service Request, the request only matches services that were registered without a scope. If it's there, the request matches services registered under that scope or unscoped ones. no cap, it's that simple 🌸
where-clause: this decides which services match. An empty where-clause matches everything. The request is also limited to services with the specified Service Type, so the where-clause isn't the only thing picking the matches 🦋
where-list: the where-list is a logical expression. It can be one single expression, a disjunction (OR) or a conjunction (AND). A single expression has to apply for the where-clause to match. A disjunction matches if any expression in its OR list matches. A conjunction matches only if all the elements in its AND list match 🔥
There's no logical negation operator, and that's on purpose. There's no concept of "give me everything except what matches this" lol so don't even try 🙈
A where-list can get nested and complicated. For example, this one requires that all three subexpressions are true:
(& (| <query-item> <query-item>)
<query-item>
(& <query-item> <query-item> <query-item>)
)Notice that white space, tabs or carriage returns can be added anywhere outside query-items. Each list has 2 or more items in it, and lists can be nested. Services that fulfill the entire logical expression match the where-clause ✨
degenerate expressions but they should be tolerated. They are equivalent to <query-item>. 💖
query-item: a query item looks like this, either as an attribute test:
'(' <attr-tag> <comp-op> <attr-val> ')'or as a bare keyword:
'(' <keyword> ')'Some examples:
(SOME ATTRIBUTE == SOME VALUE)
(RESERVED)
(QUEUE LENGTH <= 234)query-join: the query-join is a comma delimited list of conditions that the service has to satisfy to match the query. The items are treated as logically conjoined (ANDed together). So this query-join:
ATTR1=VALUE1, KEYWORD1, KEYWORD2, ATTR2>=34is the same as this where-list:
(& (ATTR1=VALUE1) (KEYWORD1) (KEYWORD2) (ATTR2>=34))The query-join can't be mixed with a where-list. It's just a handy shortcut for stating the necessary conditions without building a whole logical expression 🧚
5.4. Service Request Predicate Grammar 💜
Service Requests can describe precisely the services they need by including a Predicate in the body of the Request. This Predicate must be constructed according to the grammar below. 🎀
<predicate> ::= <srvtype>['.'<na>]'/'<scope>'/'<where>'/'
<srvtype> ::= string representing type of service. Only
alphanumeric characters, '+', and '-' are allowed.
<na> ::= string representing the Naming Authority.
Only alphanumeric characters, '+',
and '-' are allowed. If this field is
omitted then "IANA" is assumed.
<scope> ::= string representing the directory agent scope.
'/', ',' (comma) and ':' are not allowed in
this string. The scopes "LOCAL" and "REMOTE"
are reserved.
<attr-tag> ::= class name of an attribute of a given Service
Type. This tag cannot include the following
characters: '(', ')', ',', '=', '!', '>',
'<', '/', '*', except where escaped (see 17.1.)
<keyword> ::= a class name of an attribute which will have
no values. This string has the same limits
as the <attr-tag>, except that white space
internal to the keyword is illegal.
<where> ::= <where-any> |
<where-list> |
<query-join>
<where-any> ::=
That is NOTHING, or white space.
<where-list> ::= '(' '&' <where-list> <query-list> ')' |
'(' '|' <where-list> <query-list> ')' |
'(' <keyword> ')'
'(' <attr-tag> <comp-op> <attr-val> ')'
<query-list> ::= <where-list> |
<where-list> <query-list>
<query-join> ::= <keyword> |
<join-item> |
<query-join> ',' <keyword> |
<query-join> ',' <join-item>
<join-item> ::= <attr-tag> <comp-op> <attr-val>
<comp-op> ::= "!=" | "==" | '<' | "<=" | '>' | ">="
<attr-val> ::= any string (see Section 20.5 for the ways
in which attr-vals are interpreted.)
Value strings may not contain '/', ','
'=', '<', '>', or '*' except where escaped
(see 17.1.).
'(' and ')' may be used in attribute values
for the purpose of encoding a binary values.
Binary encodings (See 20.5) may
include the above reserved characters.5.5. String Matching for Requests 🌈
All strings are case insensitive when it comes to matching queries. All preceding or trailing blanks should not be considered for a match, but blanks inside a string are relevant. 💅
For example, " Some String " matches "SOME STRING", but not "some string". 🙈
String matching may only be performed over the same character sets. If a request can't be satisfied because the character set of the request isn't supported, a CHARSET_NOT_UNDERSTOOD error is returned. 😭
String comparisons (using comparison operators such as '<' or registration, not using any language specific rules. The ordering is strictly by the character value, i.e. "0" < "A" is true when the character set is US-ASCII, since "0" has the value of 48 and "A" has the value 65. ✨
The special character '' can go before or after a string to allow substring matching. If the '' comes before a string, it matches any attribute value that ends with that string. If the string ends with a '', it matches any attribute value that begins with the string. And finally, if a string begins and ends with a '', it matches any attribute value that contains the string 🦋
Examples:
"bob*" matches "bob", "bobcat", and "bob and sue"
"*bob" matches "bob", "bigbob", and "sue and bob"
"*bob*" matches "bob", "bobcat", "bigbob", and "a bob I know"String matching happens after escape sequences have been substituted. See sections 17, 5.3, 17.1. 🫶
6. Service Reply Message Format 🍓
The Service Reply Message looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvRply) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | URL Entry count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <URL Entry 1> ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
\ . \
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <URL Entry N> ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Each Service Reply message is made up of a list of URL Entries. 💖
The Error Code can be one of these values:
0 Success
LANGUAGE_NOT_SUPPORTED
A SA or DA returns this when a request is received from a
UA which is in a language for which there is no
registered Service Information and the request arrived
with the Monolingual bit set. See Section 17.
PROTOCOL_PARSE_ERROR
A SA or DA returns this error when a SrvRply is received
which cannot be parsed or the declared string lengths
overrun the message.
SCOPE_NOT_SUPPORTED
A DA will return this error if it receives a request
which has a scope not supported by the DA. An SA will not
return this error; it will simply not reply to the
multicast request.
CHARSET_NOT_UNDERSTOOD
If the DA or SA receives a request or registration in a
character set which it does not support, it will return
this error.Each <URL Entry> in the list has the form defined in Section 4.2. The URL entries in the reply have no delimiters between them, other than the length fields. The URL length fields show where each URL string ends. If the presence of a URL Authenticator block is signalled by the 'U' bit, the length of the authenticator block is determined by information inside the block, as discussed in section 4.3. A User Agent MAY use the authentication block to check whether the Service Agent advertising the URL is actually authorized to offer the indicated service 🔐
If, in a list of URL entries, some of the URLs indicate services in protected scopes (see section 16.1) while other URLs in the list indicate services that are not in protected scopes, the latter must still have Authentication Blocks, but the length of the authentcitor is shown as zero, and no authentication need be done. 🌸
7. Service Type Request Message Format ✨
okay bestie, the Service Type Request is how you find out what kinds of services are out there on a network 🔍🌸 like, every service the site has, advertised by DAs and SAs, all in one go ✨
you should send this straight to a DA (you may also send it to the Service Location General Multicast Address if you want 🦋). If there's no DA around, a User Agent MAY send more than one request so it can be sure it got every reply 💅 Each new request includes the Service Types the User Agent already knows about 🧚 And once no new replies show up within CONFIG_INTERVAL_3 of a request, the User Agent can presume it has the full list of Service Types 💖
Here's the layout 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvTypeRqst) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of prev resp string |<Previous Responders Addr Spec>|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Previous Responders Addr Spec> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of naming authority | <Naming Authority String> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Naming Authority String>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of Scope String | <Scope String> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Scope String>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the <Previous Responders Addr Spec> is a comma delimited list (see section 20.1) 🧃 The 'length of prev responder list' field tells you how long that comma delimited list string is. A previous responder list with 3 elements looks like this 👇
<addr-spec>,<addr-spec>,<addr-spec>the Naming Authority, if you include it, limits the replies to Service Types that have that Naming Authority 🏷️ If the field is left out (meaning the length field is zero), the default Naming Authority ("IANA") is assumed. If the length field is -1, you're asking for service types from all naming authorities 🌈 literally everything, no filter 😭
the Scope String Field, if included, limits replies to Service Types that have the specified scope or are unscoped 🔭 If you leave it out, you get all Service Types (from the specified Naming Authority) ✨
8. Service Type Reply Message Format 💜
the Service Type Reply is the answer to all that asking 💌 It's formatted like this 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvTypeRply) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | number of service types |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Type Item 1> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Type Item N> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+each Service Type Item looks like this 🧁
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of Service Type String | <Service Type String> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Type String>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the Error Code can be one of these values 🚦
0: Success 🎉PROTOCOL_PARSE_ERROR: an SA or DA sends this when it gets a SrvTypeRqst it can't parse 😵SCOPE_NOT_SUPPORTED: a DA that's configured with a scope sends this if it gets a SrvTypeRqst asking for a scope it doesn't support 🙅♀️ An SA won't send this one, it just quietly drops the multicast request 🤫CHARSET_NOT_UNDERSTOOD: if a DA gets a SrvTypeRqst in a character set it doesn't support, it MUST use this error 🔥
the service type's name goes in the <Service Type String> 🏷️ If the service type has a naming authority other than "IANA", it should be returned right after the service type string, separated by a "." character. Check section 20.2.1 for the formal definition of this field 📜 User Agents work out Service Specific Multicast addresses by hashing the Service Type (see Section 3.6.2) 🦋 Then they can use that multicast address to send Service and Attribute Requests straight to SAs 🚀
here are some examples of Service Type Strings you might spot in Service Type Replies 👀
service:lpr://
service:http://
service:nfs://9. Service Registration Message Format ✨
okay so once a Service Agent has found a Directory Agent 🔍, it starts registering its advertised services one at a time 💅. It has to wait a random amount of time, spread out uniformly within the range set by CONFIG_INTERVAL_11, before it registers again. Registration happens with a Service Registration message that spells out every attribute for a service 🎀. If the registration is in a protected scope 16.1, the service MUST include both a URL Authentication block and an Attribute Authentication block (see section 4.3) 🔐. In that case the service agent MUST set both the 'U' bit and the 'A' bit (see section 4) 🫶.
A Directory Agent must acknowledge each service registration request 💌. If authentication blocks are included, the Directory Agent MUST verify the authentication before registering the service 🛡️. To do that it needs the key information, which it can get through preconfiguration, by keeping a security association with the service agent, or by acquiring the right certificate 🗝️.
The format of a Service Registration is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvReg) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <URL-Entry> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Attr List String | <attr-list> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <attr-list>, Continued. \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) Attribute Authentication Block ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The <URL-Entry> is defined at the end of Section 4.2. The <attr-list> is defined in Section 20.3. The Attribute Authentication Block only shows up if the 'A' bit is set in the message header, and it's defined in section 4.3 🧩.
Service registration can ride on a connectionless protocol (e.g. UDP) or a connection oriented protocol (e.g. TCP) 🌊. If the registration might carry more information than fits in one datagram, the Service Agent MUST use a connection oriented protocol to register itself with the DA 🚀. When a Service Agent registers the same attribute class more than once for a service instance, the Directory Agent overwrites all the values associated with that attribute class for that service instance 🔄. Separate registrations must be made for each language the service is going to be advertised in 🌍.
If an SA tries to register a service with a DA and the registration is bigger than the site path MTU, the DA replies with a SrvAck. The error is set to INVALID_REGISTRATION and the 'Overflow' byte is set 🙈.
Here's an example of Service Registration information:
Lifetime (seconds): 16-bit unsigned integer
URL (at least): service:<srvtype>://<addr-spec>
Attributes (if any): (ATTR1=VALUE),KEYWORD,(ATTR2 = VAL1, VAL2)If you want to keep offering services continuously, Service Agents should start the reregistration process before the Lifetime they used in the registration expires ⏰.
Here's a service registration that's valid for 3 hours:
Lifetime: 10800
URL: service:lpr://igore.wco.ftp.com:515/draft
Attributes: (SCOPE=DEVELOPMENT),
(PAPER COLOR=WHITE),
(PAPER SIZE=LETTER),
UNRESTRICTED_ACCESS,
(LANGUAGE=POSTSCRIPT, HPGCL),
(LOCATION=12 FLOOR)The same registration can be sent again in German, like below. Heads up though: "lpr", "service", and "SCOPE" are reserved terms, so they stay in the language they were first registered in (English) 🇬🇧.
Lifetime: 10800
URL: service:lpr://igore.wco.ftp.com:515/draft
Attributes: (SCOPE=ENTWICKLUNG),
(PAPIERFARBE=WEISS),
(PAPIERFORMAT=BRIEF),
UNBEGRENTZTER_ZUGANG,
(DRUECKERSPRACHE=POSTSCRIPT,HPGCL),
(STANDORT=11 ETAGE)Scoped registrations must contain the SCOPE attribute 🎯. Unscoped registrations must be registered with all unscoped Directory Agents 🌐.
Registering a service that's already registered counts as an update 🔁. If that attribute registration happens in a protected scope (see section 16.1), a new Attribute Authentication block must also be included, and the 'A' bit has to be set in the registration message header 🔐.
The new registration's attributes replace the old ones, but they don't effect attributes that were included earlier and aren't in the update 💫.
For example, say service:x://a.org was registered with attributes A=1, B=2, C=3. If a new registration comes in for service:x://a.org with attributes C=30, D=40, then after the update the attributes for that service are A=1, B=2, C=30, D=40 🧁.
In the example above, the SCOPE is DEVELOPMENT (in English) and ENTWICKLUNG (in German). Remember that every string in a message has to be in one language, and that language is specified in the header 📝. The string SCOPE is not translated, because it's one of the reserved strings in the Service Location Protocol (see section 17.2.) 🔒
The Directory Agent can send back a server error in the acknowledgment 📨. The error shows up in the Error Codes field of the service location message header. A Directory Agent MUST decline to register a service if that service is specified with a scope it doesn't support 🙅♀️. In that case a SCOPE_NOT_SUPPORTED error is returned in the SrvAck. A Directory Agent MUST NOT accept Service Registrations that have an unsupported scope, unless it's an unscoped Directory Agent. In that case it MUST accept all Service Registrations 🫧.
An unscoped Service Registration will match all requests 🌈. So a request for a certain scope will return the services that have that scope and the services that are unscoped 🧲. It's strongly suggested that you use scopes in all registrations or in none 💜. See Sections 16 and 3.7 for details.
When the URL entry that comes with a registration also contains an authentication block (section 4.3), the DA MUST perform the indicated authentication, and then report the results in the Service Acknowledgement message 📋.
10. Service Acknowledgement Message Format 💅
A Service Acknowledgement gets sent once a DA has received and processed a Service Registration or Service Deregistration 💌. An acknowledgment that means success must have the error code set to zero ✅. Once a DA acknowledges a service registration, it makes that information available to clients 🎉.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvAck) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Error Code may be one of these values:
0 Success
PROTOCOL_PARSE_ERROR
A DA returns this error when the SrvReg or SrvDereg is
received which cannot be parsed or the declared string
lengths overrun the message.
INVALID_REGISTRATION
A DA returns this error when a SrvReg or SrvDeReg is
invalid. For instance, an invalid URL, unknown or
malformed attributes, or deregistering an unregistered
service all cause this error to be reported.
SCOPE_NOT_SUPPORTED
A DA which is configured to have a scope will return this
error if it receives a SrvReq which is set to have a
scope which it does not support.
CHARSET_NOT_UNDERSTOOD
If the DA receives a SrvReg or SrvDereg in a character
set which it does not support, it will return this error.
AUTHENTICATION_ABSENT
If DA has been configured to require an authentication
for any service registered in the requested scope, and
there are no authentication blocks in the registration,
the DA will return this error.
AUTHENTICATION_FAILED
If the registration contains an authentication block
which fails to match the correct result as calculated
(see section 4.3) over the URL or attribute data to be
authenticated, the DA will return this error.If the Directory Agent accepts a Service Registration and already has an existing entry for it, it updates that entry with the new lifetime information, plus any new attributes and new attribute values ♻️. Otherwise, if the registration is acceptable (including all the necessary authentication checks), the Directory Agent creates a new entry and sets the 'F' bit in the Service Acknowledgement it sends back to the Service Agent 🦋.
11. Service Deregister Message Format 💅
Okay bestie, when a service goes offline, the Service Agent must deregister itself from every Directory Agent it was registered with 🥺 Otherwise people keep getting sent to a service that isn't there anymore, which is so not it. 💀 A service does this with the following PDU:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvDereg) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of URL | URL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ URL of Service to Deregister, contd. \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) authentication block .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <tag spec> string | <tag spec> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <tag spec>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+So if the Directory Agent doesn't respond, the Service Agent should retry the operation ✨ The Directory Agent answers with a Service Acknowledgment message 🫶 Once the Service Agent gets an acknowledgment that says success, it can assume that the Directory Agent isn't advertising the service anymore. 🎉 The Error Code in that Acknowledgment of the Service Deregistration may have the same values as described in section 10 💖
The Service Deregister Information sent to the Directory Agent looks like this:
service:<srvtype>://<addr-spec>
Attribute tags (if any): ATTR1,KEYWORD,ATTR2This deregisters the specified attributes from the service information held by the Directory Agent 🧚 If you don't include any attribute tags, the entire service information gets deregistered in every language and every scope it was registered in. 💅 To deregister the printer from the example before, use:
service:lpr://igore.wco.ftp.com:515/draft🚨 If the service was originally registered with a URL entry that contains a URL authentication block, then the Service Deregistration message header MUST have the 'U' bit set. The URL entry is then followed by the authentication block, and the authenticator is calculated over the URL data, the timestamp, and the length of the authenticator, as explained in section 4.3. In this calculation, the lifetime of the URL data counts as zero, no matter what the remaining lifetime of the registered URL currently is. 😭
12. Attribute Request Message Format 🔍
The Attribute Request is how you go looking for attribute info 👀 The UA sends a request, and the right attribute info comes back to it. 🦋
If the UA only supplies a Service Type, the reply includes all attributes and all values for that Service Type 🌈 But the reply only includes attributes for which services exist and are advertised by the DA or SA that got the Attribute Request. ✨ Different instances of a given service can, and very likely will, have different values for the attributes defined by the Service Type, so the User Agent must form a union of all attributes returned by all service Agents. 🧠 That attribute info is what gets used to build Service Requests. 🎀
If the UA supplies a URL, the reply contains the service information for that URL 💜
Attribute Requests also include a 'select clause' 💅 It can limit how much info comes back. If the select clause is empty, you get everything. Otherwise, the UA gives a comma delimited list of attribute tags and keywords. If the attribute or keyword is defined for a service, it gets returned in the Attribute Reply, along with all registered values for that attribute. ✨ If the selected attribute hasn't been registered for that URL or Service Type, the attribute or keyword info is just not returned. 🙈
The Attribute Request message looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = AttrRqst) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|length of prev resp list string|<Previous Responders Addr Spec>|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Previous Responders Addr Spec>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of URL | URL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ URL, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <Scope> | <Scope> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Scope>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <select-list> | <select-list> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <select-list>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The <Previous Responder Address List> works exactly like what we covered in Section 7 💫 See also Section 20.1 📚
The URL can take two forms 🌸 It can be just a Service Type, like service:http:, or a full URL, like service:lpr://igore.wco.ftp.com:515/draft. With the Service Type form, you get all attributes and the full range of values for each attribute for that Service Type. With the URL form, you only get the attributes for the service whose URL is defined. 💖
The Scope String exists so Attribute Requests for Service Types can return only the attribute info for one specific scope 🎯 This field gets ignored when a full URL is sent in the Attribute Request. The rules for encoding the Scope String are in Section 5.4 🧁
The select list looks like this:
<select-list> ::= <select-item> |
<select-item> ',' <select-list>
<select-item> ::= <keyword> | <attr-tag> | <partial-tag> '*'
<partial-tag> ::= the partial class name of an attribute
If followed by an '*', it matches all class names
which begin with the partial tag. If preceded by
a partial tag. If both preceded and followed by
'*' it matches all class names which contain the
partial tag.For the definitions of <attr-tag> and <keyword>, check out 5.4 🤓
An example select-list for the printer one is:
PAGES PER MINUTE, UNRESTRICTED_ACCESS, LOCATIONIf you send this to a Directory Agent, the number of previous responders is zero and there's no Previous Responder Address Specification. 🙃 Those fields are only used for repeated multicasting, exactly like in the Service Request. 🔁
13. Attribute Reply Message Format 🎁
An Attribute Reply Message looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = AttrRply) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | length of <attr-list> string |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <attr-list> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Error Code can have these values 🚨
0means Success ✅LANGUAGE_NOT_SUPPORTEDis returned by a SA or DA when a request comes from a UA in a language with no registered Service Information, and the request arrived with the Monolingual bit set. See Section 17 🌍PROTOCOL_PARSE_ERRORis returned by a DA or SA when an AttrRqst comes in that can't be parsed, or when the declared string lengths overrun the message. 😵SCOPE_NOT_SUPPORTEDis returned by a DA that's configured to have a scope if it gets an AttrRqst set to a scope it doesn't support. SAs silently discard multicast AttrRqst messages for scopes they don't support. 🤫CHARSET_NOT_UNDERSTOODis returned if the DA gets an AttrRqst in a character set it doesn't support. SAs silently discard multicast AttrRqst messages that arrive in character sets they don't support. 🈳
The <attr-list> (attribute list) has the same form as the attribute list in a Service Registration. See Section 20.3 for the formal definition of this field 📝
An Attribute Request for "lpr" might get back this reply (UNRESTRICTED_ACCESS is a keyword):
(PAPER COLOR=WHITE,BLUE),
(PAPER SIZE=LEGAL,LETTER,ENVELOPE,TRACTOR FEED),
UNRESTRICTED_ACCESS,
(PAGES PER MINUTE=1,3,12),
(LOCATION=12th, NEAR ARUNA'S OFFICE),
(QUEUES=LEGAL,LETTER,ENVELOPE,LETTER HEAD)If the message header has the 'A' bit set, the Attribute Reply will have an Attribute Authentication block set 🔐 In that case, the Attribute Authenticator must be returned with the entire list of attributes, exactly as an SA registered it in a protected scope. 🛡️ Here, the URL was registered in a protected scope and the UA included a URL but no select clause. If the AttrRqst asks for only certain attributes, the DA does not (typically cannot) compute a new Authenticator, so it just returns the attributes without an authenticator block. 🙏
A UA that wants authenticated attributes for a service in a protected scope MUST therefore must include a particular URL and no select list with the AttrRqst. 🔥 No shortcuts, periodt 💅
14. Directory Agent Advertisement Message Format ✨
okay so bestie, this is the DA Advertisement message format 💅 DA Advertisement Messages look like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = DAAdvert) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Length of URL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ URL \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <Scope-list> | <Scope-list> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Scope-list>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Error Code is only filled in when a DA Advertisement comes back as the result of a Service Request 🎀 For an unsolicited DA Advertisement it's always going to be 0. The Error Code may take the values specified in Section 6.
The URL is where the Directory Agent lives 📍 The <Scope-list> is a comma-delimited list of the scopes the DA supports, and it looks like this:
<Scope-list> ::= <Scope> | <Scope-list> ',' <Scope>
<Scope> ::= String representing a scopeSee Section 5.4 for the lexical rules regarding <Scope> 🧚
DA Advertisements sent in reply to a Directory Agent Discovery Request have the exact same format as the unsolicited ones. For example:
URL: service:directory-agent://SLP-RESOLVER.CATCH22.COM
SCOPE List: ADMINSo the Directory Agent can be reached at the Address Specification that gets returned, and it supports the SCOPE called "ADMIN" 👑
15. Directory Agents
15.1. Introduction
okay so a Directory Agent is basically the main character 🦋 It acts on behalf of a whole bunch of Service Agents, collects their info, and then becomes the one single point of contact that hands that info over to User Agents. iconic, honestly.
The queries a User Agent multicasts to Service Agents (in an environment without a Directory Agent) are the same queries it might unicast to a Directory Agent. A User Agent may cache information about the presence of alternate Directory Agents so it has a backup to use in case the one it picked fails 🫶
Running multiple DAs is about more than just scalability (see section 3.7). It also gives you robustness 💪 The DAs may have replicated service information that stays accessible even when one of them goes down. In the future, Directory Agents may use mechanisms outside of this protocol to coordinate a distributed database of Service Location information, so they can scale up to enterprise networks or bigger administrative domains 🌈
Each Service Agent must register with all DAs it is configured to use. UAs may choose among the DAs they are configured to use 🍓
Locally, Directory Agent consistency is guaranteed using mechanisms in the protocol. There isn't a Directory to Directory Agent protocol yet 🙈 Instead, passive detection of DAs by SAs makes sure service information eventually gets registered consistently between DAs. Invalid data ages out of the Directory Agents, leaving only transient stale registrations, even if a Service Agent fails 💜
15.2. Finding Directory Agents
A User or Service Agent may be statically configured to use a particular DA. This is discouraged unless the application lives on a network where any form of multicast or broadcast is impossible 🙅♀️
Alternatively, a host that uses DHCP [2, 11] may use it to get a Directory Agent's address. DHCP options 78 and 79 have been assigned for this purpose [21] 🎀
The third way to find DAs is dynamically, by sending out a Directory Agent Discovery request (see Section 5.2) ✨
Lastly, the agent may be informed passively, like this:
When a Directory Agent first comes on-line, it sends an unsolicited DA Advertisement to the Service Location general multicast address. If a DA supports a particular scope or set of scopes, those get placed in the reply. The class for this attribute is 'SCOPE'.
Every CONFIG_INTERVAL_9 a Directory Agent sends an unsolicited DA Advertisement. This makes sure it eventually gets discovered by all the applications that care 🌸
When a Directory Agent first comes up, it begins with 0 as its XID, and it increments this by one each time it sends an unsolicited DA Advertisement. When the counter wraps, it should go from 0xFFFF to 0x0100, not 0 🔥
If the Directory Agent has stored all of its service information in a nonvolatile store, it should initially set the XID to 0x100, because it's not coming up 'stateless.' If it stores service registrations in memory only, it will restart with no state at all. In that case, it should indicate this by resetting its XID to 0 💀
All Service Agents that receive the unsolicited DA Advertisement should examine its XID. If the Directory Agent has never been heard from before, or if the XID is less than it was previously and also less than 256, the Service Agent should assume the DA doesn't have its service registration, even if it once did. If that's the case and the DA has the proper scope, the SA should register all of its service information with the Directory Agent, after waiting a random interval of CONFIG_INTERVAL_10 ⭐
When a Service Agent or User Agent first comes online, it must issue a Directory Agent Discovery Request, unless it's using static or DHCP configuration, as described in 5.2 🧚
A Service Agent registers information with ALL newly discovered Directory Agents when either of the above two events takes place. When scopes are being used, a Service Agent SHOULD choose a set of scopes to be advertised in, and it only needs to register with Directory Agents that support the scopes it wants to be registered in 💅 Services MUST be registered with DAs that support their scope and with those that have no scope, unless specifically configured not to do so (see section 22.1.)
Once a User Agent becomes aware of a Directory Agent, it will unicast its queries there. If more than one Directory Agent is detected, it will select one to talk to. When scopes are supported, the User Agent will direct its queries to different Directory Agents depending on which scopes are the appropriate domains for the query to be answered in 🦋
The protocol will cause all DAs (of the same scope) to eventually end up with consistent information. So one DA is as good as any other for getting service information. There may be temporary inconsistencies between DAs, though 🌈
16. Scope Discovery and Use
The scope mechanism is what makes the Service Location Protocol scalable 🌟 Scopes are mainly for organizing a site network along administrative lines. A set of services can be assigned to a given department of an organization, to a certain building or geographical area, or to a certain purpose. Users can be shown these organizational elements as a top-level selection before they go looking for services inside a domain 🫶
A site network that has grown too big for a few DAs to reasonably serve can use the scope mechanism. DAs have the attribute class "SCOPE". The values for this attribute are a list of strings that represent the administrative areas this Directory Agent is configured for. The semantics and language of those strings are almost entirely up to the administrative entity of the domain they belong to 🎀 The values of SCOPE should be configurable, so the system administrator can set them. The scopes "LOCAL" and "REMOTE" are reserved and SHOULD NOT be used. Using these reserved values is to be defined in a future protocol document 🙈
Services with the attribute SCOPE should only be registered with DAs that support the same scope, or with DAs that have no scope 💜
Directory Agents advertise their available scopes 📣 A Service Agent may then choose a scope to register in, and SHOULD register with all Directory Agents in that scope, as well as all DAs that have no scope. If a Service Agent isn't comprehensive about registration under this rule, the service advertisement may not be available to all User Agents 😭
A Directory Agent that has a scope will return advertisements in response to Directory Agent Discovery requests, with the scope information included. Note that the "service:directory-agent" scheme is registered with the IANA naming authority (which gets selected automatically by leaving the Naming Authority field empty) 🧚
The query:
directory-agent/MATH DEPT//Could receive the following DA Advertisement:
Returned URL: service:directory-agent://diragent.blah.edu
Returned SCOPE: MATH DEPTThe same Directory Agent, if it had no scope value, would reply:
Returned URL: service:directory-agent://diragent.void.com
Returned SCOPE:If a Directory Agent supported more than one scope, it would reply like this:
Returned URL: service:directory-agent://srv.domain.org
Returned SCOPE: MATH DEPT,ENGLISH DEPT,CS DEPTA DA that has no scope will reply to any Directory Agent Discovery Request 🌸
Being a member of a scope means that an agent SHOULD use the Directory Agents that support its scope. User Agents send all requests to DAs that support the indicated scope. Services are registered with the DA(s) in their scope. For a UA to find a service registered in a particular scope, it must send requests to a DA that supports the indicated scope. There's no limit on scope membership built into the protocol, meaning a User Agent or Service Agent can be a member of more than one scope. Membership is open to all, unless some external authorization mechanism is added to limit access 🌈
16.1. Protected Scopes 🔐
Okay bestie, scope membership MAY also define the security access and authorization for services in the scope, and these are called protected scopes 🛡️. If a User Agent wants to be totally sure that Service Agents are allowed to provide the service they advertise, it should request services from a protected scope that's been set up with the right authentication mechanism, with keys handed out to the Service Agents inside it 🗝️. A directory agent that's passing out URLs for a protected scope will reject any registration or deregistration from a service agent that can't show cryptographically strong authentication proving it's authorized to offer those services. No cap, this is a whole vibe 💅
For instance, say a campus registrar needs a working printer to print student grade information for mailing 🖨️. The registrar would require the printing user agent to send the printable output only to those printing Service Agents that have been registered in the right protected scope. Notice that each service agent is, under normal circumstances, validated two times ✌️: once when it registers with the directory agent, and once when the user agent checks the URL it got back in the Service Reply. This protects against malicious Directory Agents and malicious Service Agents 🦋
Note that services in protected scopes provide separate authentication for their URL entry and for their attributes 🎀. This follows naturally from how the protocol works. User Agents that specify a service type and the attributes needed for service in that service type won't get attribute information from the directory agent. They'll only get the appropriate URL entries. Only the information that's returned needs to be authenticated.
User agents that receive attribute information for a particular URL (see section 12), on the other hand, need to authenticate the attributes when they come back (see section 13). In this case there may be a lot more data to authenticate, but this happens way less often, usually only while the user is browsing the available network resources 🌸
17. Language and Character Encoding Issues 🌍
Okay so every Service Registration declares the language its attribute strings are written in, by putting the right code in the message header 💬. For each language the Service advertises, a separate registration happens. Each of these registrations uses the same URL to show they're all about the same service 🔗.
If a Service is fully deregistered (the URL is given in the Service Deregister request, with no attribute information), then the Service only needs to be deregistered once. That one deregistration effectively removes the service in every language it was registered in ✨
If attribute information is included in the Service Deregistration request, then a separate Service Deregistration of selected attributes has to happen in each language where a Service Agent gave the DA service information 🌈. Service Registrations in different languages are mutually unintelligible. The only things they share are their service type and the URL they were registered with 🙈. No attempt is made to match queries with "language independence." Instead, queries are handled with string matching against registrations in the same language as the query 💅
Service Types that are standardized will have definitions for all attributes and value strings 📜. Official translations of the attribute tags and values into other languages can be made and submitted as part of the standard, but that isn't doable for every language 😭. For languages that aren't defined as part of the Service Type, a best effort translation of the standard definitions of the Service Type's attribute strings MAY be used 🍓
All Service Requests specify a requested language in the message header 🗣️. The Directory Agent or Service Agent will respond in the same language as the request, if it has a registration in that language. If that language isn't supported and the Monolingual bit is not specified, a reply can be sent in the default language (which is English.) If the 'monolingual bit' flag in the header is set and the requested language isn't supported, a SrvRply comes back with the error field set to LANGUAGE_NOT_SUPPORTED 🚫
If a query is in a supported language on a SA or DA, but uses a different dialect than the available service information, the query MUST be serviced on a best-effort basis. If possible, the query should be matched against the same dialect. If that's not possible, it MAY be matched against any dialect of the same language 🌷
Heads up: the MUST and MAY above are the only places in this section where the requirement words are capitalized, so they're the ones you really need to clock 👀
17.1. Character Encoding and String Issues 🔤
Values for character encoding can be found in IANA's database at http://www.isi.edu/in-notes/iana/assignments/character-sets, and they're referred to by their MIBEnum value 📚.
The encoding decides how all the character data that comes after the Service Location Protocol header gets interpreted. There's no way to mix ASCII and UNICODE, for example 🙅♀️. All responses must be in the character set of the request, or use US-ASCII. If a request goes to a DA or SA, or a registration goes to a DA, that can't handle or store the character set of the incoming message, the request will fail 💀. In that case the SA or DA returns a CHARSET_NOT_UNDERSTOOD error in a SrvAck message. Requests using US-ASCII will never fail for this reason, since all SAs and DAs have to be able to accept this character set ✨
Certain characters are illegal in certain contexts of the protocol. Since the protocol is pretty much character-string based, characters are used as protocol delimiters in some contexts. In those cases, the delimiting characters must not be used as 'data text.' 🚧
17.1.1. Substitution of Character Escape Sequences 🧩
The Service Location Protocol has an 'escape mechanism' that's consistent with HTTP 2.0 [5] and SGML [15] 🍰. If the character sequence &# is followed by one or more digits and then a semicolon ;, the entire sequence gets interpreted as a single character. The digits are read as a decimal value in the character set of the request, as specified by the header. So in US-ASCII, , is interpreted as a comma 🪄. Substitution of these escape strings must be done in all <attr-list> and strings present in SrvReq and AttrRqst messages. Only numerical character references are accepted, not 'Entity References,' as defined in HTML. These escape values should only be used to include reserved characters in attribute tag and value strings 🎀
The interpretation of these escape values is different from HTML in one way: in HTML the escape values are considered to be in the ISO Latin-1 character set. In Service Location, they're interpreted in the character set defined in the header of the message 🤓
This escape mechanism lets characters like commas show up in attribute tags and values, which would otherwise be illegal since the comma is a protocol delimiter 🙌
Attribute tags and values of different languages are considered mutually unintelligible. A query in one language SHOULD use service information registered in that language 💜
17.2. Language-Independent Strings 🧸
Some strings, like Service Type names, have standard definitions. These strings should be treated as tokens, not as words in a language to be translated 🪪
Reserved String Section xDefinition
--------------- ------- --------------------------------------
SCOPE 3, 15 Used to limit the matching of requests.
SERVICE 6, 9 The URL scheme of all Service Location
information registered with a DA or
returned from a Service Request.
<srvtype> 20.2.1 Used in all service registrations
and replies.
domain names 20.4 A fully qualified domain name, used
in registrations and replies.
IANA 3.3 The default naming authority.
LOCAL 16 Reserved.
REMOTE 16 Reserved.
TRUE 20.5 Boolean true.
FALSE 20.5 Boolean false.18. Service Location Transactions 🦋
18.1. Service Location Connections 🔌
When a Service Location Request or Attribute Request gets a UDP reply from a Service or Directory Agent that would overflow a datagram, the User Agent can open a connection to the Agent and reissue the request over it 🌊. The reply comes back with the overflow bit set (see section 4) and contains as much data as will fit into a single datagram. If no MTU information is available for the route, assume the MTU is 1400. This value is configurable (see section 22) ⚙️
When a request results in overflowed data that can't be parsed correctly (say, because of duplicate or dropped IP datagrams), a User Agent that wants to reliably get the overflowed data must establish a TCP connection with the Directory Agent or Service Agent that has the data 🛠️. When the request is sent again with a new XID, the reply comes back over the connection 💫
When registration data is longer than one datagram, the Service Registration should be made by opening a connection to a Directory Agent and sending the registration over the connection stream 📨
Directory Agents and Service Agents must respond to connection requests. Services whose registration data can overflow a datagram must be able to use TCP to send the registration. User Agents should be able to make Service and Attribute Requests using TCP. If they don't implement this, they must be able to interpret partial replies and/or reissue requests with more selective criteria to shrink the size of the replies 🫶
A connection started by an Agent may be used for a single transaction. It may also be used for multiple transactions. Since there are length fields in the message headers, Agents may send multiple requests along a connection and read the return stream for acknowledgments and replies 🧃
The initiating agent is responsible for closing the TCP connection. The DA should wait at least CONFIG_INTERVAL_12 before closing an idle connection. DAs and SAs SHOULD eventually close idle connections to keep things robust, even when the agent that opened a connection forgets to close it 🧹
18.2. No Synchronous Assumption 🙃
There's no requirement that one transaction completes before a given host starts another. An agent can have multiple outstanding transactions, started either with UDP or TCP 🏃♀️💨
18.3. Idempotency 🔁
All Service Location actions are idempotent. Of course, registration and deregistration will change the state of a DA, but repeating these actions with the same XID will have exactly the same effect each time 💖. Repeating a registration with a new XID has the effect of extending the lifetime of the registration ⏳
19. Security Considerations 🔐
okay bestie, security time, and it's kind of a big deal 😭 SLP has authentication for Service Agents built into the scope mechanism, so the data in registrations comes with integrity 🔒. BUT it does not do confidentiality, so nothing is hidden 🙈. Since the whole point is advertising services to a community of users, confidentiality might not really be needed in non-sensitive environments. Specialized schemes might be able to add it later if it turns out to be needed 🦋. Sites that DO need confidentiality should implement the IP Encapsulating Security Payload (ESP) [3] to protect Service Location messages 💅.
🚨 Big warning, bestie: if you use unprotected scopes, an attacker can totally advertise services from their own servers and sneakily get access to users' private info 😱. They'll also find selective denial of service attacks way easier 💀. Sites in potentially hostile environments (e.g. directly connected to the Internet) should consider the advantages of distributing keys for protected scopes before deploying the sensitive directory agents or service agents 🔑.
SLP is also a super useful bootstrap protocol 🧚. It can be used where no preconfiguration is possible at all. The catch is that a certain amount of "blind faith" is required 🙈. Without any prior configuration, you literally cannot use any of the security mechanisms above. SLP will use the key distribution mechanisms the IETF Security Area provides as they become available. Right now, the protected-scope benefits only happen if some cryptographic info gets preconfigured on the end systems before they use SLP. For User Agents, that can be as simple as supplying the public key of a Certificate Authority. See Appendix B 🎀.
20. String Formats used with Service Location Messages ✨
okay so this section has all the formal definitions for the fields and protocol elements introduced earlier 📝. Here's the lookup table:
Protocol Element Defined in Used in
----------------------------------- ------------ ------------
<Previous Responders' Addr Spec> 20.1 SrvReq
Service Request <predicate> 5.4 SrvReq
URL 20.2 SrvReg,
SrvDereg,
SrvRply
<attr-list> 20.3 SrvReg,
SrvRply,
AttrRply
<Service Registration Information> 9 SrvReg
<Service Deregister Information> 11 SrvDereg
<Service Type String> 20.2.1 AttrRqst20.1. Previous Responders' Address Specification 📍
The previous responders' Address Specification is written like this:
<Previous Responders' Address Specification> ::=
<addr-spec> |
<addr-spec>, <Previous Responders' Address Specification>So, to put it plainly, it's a list separated by commas with no white space in between. Each address is the Directory Agent or Service Agent that sent the previous response. The format for Address Specifications is in section 20.4. The comma delimiter is required between each <addr-spec>. Dotted decimal IP address notation should only be used in environments that have no Domain Name Service.
Example:
RESOLVO.NEATO.ORG,128.127.203.6320.2. Formal Definition of the "service:" Scheme 🌸
A URL with a "service:" scheme shows up in the SrvReg, SrvDereg, SrvRply and AttrRqst messages. URLs are defined in RFC 1738 [6]. A URL with the "service:" scheme must contain at least this:
<url> ::= service:<srvtype>://<addr-spec>Here's what each piece means:
service: the URL scheme for Service Location, to return Replies.<srvtype>: a string. Service Types can be standardized by writing a specification for the "service type"-specific part and registering it with IANA. See sections 20.2.1 and 3.3.<addr-spec>: the service access point of the service. It's the network address or domain name where the service can be accessed. See section 20.4.
The "service:" scheme may be followed by any legal URL. The a particular service. The protocol used to access the service at the given service access <addr-spec> may be implicit in the Service Type name. If that isn't the case, the Service Type MUST be defined in a way that attribute information includes all the necessary configuration and protocol information. A User Agent MUST therefore be able to use either a "service:" URL alone, or a "service:" URL combined with service attributes, to make use of a service 💖.
20.2.1. Service Type String 🏷️
The Service Type is a string that describes the type of service. These strings may only be comprised of alphanumeric characters, '+', and Type names.
If the Service Type name is followed by a '.' and a string (which has the same limitations), that 'suffix' counts as the Naming Authority of the service. If the Naming Authority is omitted, IANA is assumed to be the Naming Authority.
Service Types made for in-house or experimental use can have any name and attribute semantics, as long as they don't conflict with the standardized Service Types 🧪.
20.3. Attribute Information 🎀
The <attr-list> is returned in the Attribute Reply if the Attribute Request doesn't come back empty.
<attr-list> ::= <attribute> | <attribute>, <attr-list>
<attribute> ::= (<attr-tag>=<attr-val-list>) | <keyword>
<attr-val-list> ::= <attr-val> | <attr-val>, <attr-val-list>An <attr-list> must be scanned before evaluation for all occurrences of the string "&#" followed by one or more digit followed by ';'. See Section 17.1.1.
A keyword has only an <attr-tag>, and no values.
A comma cannot appear in an <attr-val>, because the comma is the multiple value delimiter. Examples of an <attr-list> are:
(SCOPE=ADMINISTRATION)
(COLOR=RED, WHITE, BLUE)
(DELAY=10 MINS),BUSY,(LATEST BUILD=10-5-95),(PRIORITY=L,M,H)The third example has three attributes in the list. Color can take on the values red, white and blue. There are several other examples of replies throughout the document 🌈.
20.4. Address Specification in Service Location 📬
The address specification used in Service Location looks like this:
<addr-spec> ::= [<user>:<password>@]<host>[:<port>]
<host> ::= Fully qualified domain name |
dotted decimal IP address notationWhen no Domain Name Server is available, SAs and DAs must use dotted decimal conventions for IP addresses. Otherwise, it's preferable to use a fully qualified domain name wherever possible, because renumbering of host addresses will make IP addresses invalid over time 🙃.
Generally, only the host domain name (or address) is returned. When there's a non-standard port for the protocol, that should be returned as well. Some applications may use the <user>:<password>@ syntax, but it isn't encouraged in this context until mechanisms are established to maintain confidentiality 🔐.
Address specification in Service Location is consistent with standard URL format [6].
20.5. Attribute Value encoding rules 🧁
Attribute values and attribute tags are CASE INSENSITIVE for lexical comparison purposes.
Attribute values are strings that can contain any characters, with the exception of '(', ')', '=', '>', '<', '/', '*', and ',' (the comma). The exception is the case described below, where opaque values are encoded. These characters can be included using the character value escape mechanism in section 17.1.1.
An attribute can take any value, but there are three types of values that stand out from general strings: Booleans, Integers and Opaque values 👑.
- Boolean values are either "TRUE" or "FALSE". This is true regardless of language (i.e. in French or Telugu, Boolean TRUE is "TRUE", same as in English.) Boolean attributes can take only one value.
- Integer values are expressed as a sequence of numbers. The range of allowable values for integers is "-2147483648" to "2147483647". No other form of numeric representation is interpreted as an integer. For example, hexadecimal numbers such as "0x342" are not interpreted as integers, but as strings.
- Opaque values (i.e. binary values) are expressed in radix-64 notation. The syntax is:
<opaque-val> ::= (<len>:<radix-64-data>)
<len> ::= number of bytes of the original data
<radix-64-data> ::= radix-64 encoding of the original data<len> is a 16-bit binary number. Radix-64 encodes every 3 bytes of binary data into 4 bytes of ASCII data, which is in the range of characters that are fully printable and transferable by mail. For a formal definition of the Radix-64 format, see RFC 1521 [7], MIME Part One, Section 5.2 Base64 Content Transfer Encoding, page 21 🦋.
21. Protocol Requirements 📋
this section lists the various protocol requirements for User Agents, Service Agents, and Directory Agents. Let's get into it 💅.
21.1. User Agent Requirements 💅
okay bestie, let's get into what a User Agent is allowed to do 🫶 A User Agent MAY:
- Provide a way for the application to configure the default DA, so that it can be used without needing to find it each initially. 🌸
- Be able to request the address of a DA from DHCP, if configured to do so. 🦋
- Ignore any unauthenticated Service Reply. 🙈
- Be able to issue requests in any language or character set provided that it can switch to the default language and character set if the request can not be serviced by DAs and SAs at the site. 🌈
- Require an authentication block in any URL entry returned as part of a Service Request, before making use of the advertised service. 💜
A User Agent SHOULD:
- Try to contact DHCP to obtain the address of a DA. ✨
- Use a scope in all requests, if possible. 🎀
- Issue requests to scoped DAs if the UA has been configured with a scope. 🍓
- Listen on the Service Location General Multicast address for unsolicited DA Advertisements. This will increase the set of Directory Agents available to it for making requests. See Section 15.2. 👑
- Be able to be configured to require an authentication block in any received URL entry advertised as belonging to a protected scope, before making use of the service. 🔐
ngl, if the UA does not listen for DA Advertisements, new DAs will not be passively detected 💀 A UA which does not have a configured DA, has not yet discovered one, and is not listening for unsolicited DA Advertisements will remain ignorant of DAs. It may then do a DA discovery before each query performed, or it may simply use multicast queries to Service Agents. main character energy of the UA is really about how it finds its DAs 🧚
A User Agent MUST:
- Be able to unicast requests and receive replies from a DA. Transactions should be made reliable by using retransmission of the request if the reply does not arrive within a timeout interval. 💖
- Be able to detect DAs using a Directory Agent Discovery request issued when the UA starts up. 🌟
- Be able to send requests to a multicast address. Service Specific Multicast addresses are computed based on a hash of the Service Type. See Section 3.6.2. 💅
- Be able to handle numerous replies after a multicast request. The implementation may be configurable so it will either return the first reply, all replies until a timeout, or keep trying till the results converge. 🔥
- Ignore any unauthenticated Service Reply or Attribute Reply when an appropriate IPSec Security Association for that Reply exists. 🛡️
- Whenever it obtains its IP address from DHCP in the first place, also attempt to obtain scope information, and the address of a DA, from DHCP. 🎀
- Use the IP Authentication Header or IP Encapsulating Payload in all Service Location messages, whenever an appropriate IPSec Security Association exists. 🔒
- Be able to issue requests using the US-ASCII character set. 🌸
- If configured to use a protected scope, be able to use "md5WithRSAEncryption" [4] to verify the signed data. 🫧
21.2. Service Agent Requirements 🧚
okay so the Service Agent has its own list of vibes 💖 A Service Agent MAY be able to:
- Get the address of a local Directory Agent by way of DHCP. 🦋
- Accept requests in non-US-ASCII character encodings. This is encouraged, especially for UNICODE [1] and UTF-8 [24] encodings. 🌈
- Register services with a DA in non-US-ASCII character encodings. This is encouraged, especially for UNICODE [1] and UTF-8 [24] encodings. ✨
A Service Agent SHOULD be able to:
- Listen to the service-specific multicast address of the service it is advertising. The incoming requests should be filtered: if the Address Specification of the SA is in the Previous Responders Address Specification list, the SA SHOULD NOT respond. Otherwise, a response to the multicast query SHOULD be unicast to the UA which sent the request. 🙈
- Listen for and respond to broadcast requests and TCP connection requests, to the Service Location port. 📡
- Be configurable to calculate authentication blocks and thereby be enabled to register in protected scopes. This requires that the service agent be configured to possess the necessary keys to calculate the authenticator. 🔑
A Service Agent MUST be able to:
- Listen to the Service Location General Multicast address for queries (e.g., Service Type Requests). If the query can be replied to by the Service Agent, the Service Agent MUST do so. 💅
It MUST check first to make sure it is not on the list of 'previous responders.' 👀
- Listen to the Service Location General Multicast address for unsolicited DA Advertisements. If one is detected, and the DA has the right scope (or has no scope), all services which are currently being advertised MUST be registered with the DA (unless configured to only use a single DA (see section 22.1), or the DA has already been detected, subject to certain rules (see section 15.2)). 🔥
- Whenever it obtains its IP address from DHCP in the first place, also attempt to obtain scope information, and the address of a DA, from DHCP. 🎀
- Unicast registrations and deregistrations to a DA. Transactions should be made reliable by using retransmission of the request if the reply does not arrive within a timeout interval. 💌
- Be able to detect DAs using a Directory Agent Discovery request issued when the SA starts up (unless configured to only use a single DA, see section 22.1.). 🌟
- Use the IP Authentication Header or IP Encapsulating Payload in all Service Location messages, whenever an appropriate IPSec Security Association exists. 🔒
- Be able to register service information with a DA using US-ASCII character encoding. It must also be able to reply to requests from UAs which use US-ASCII character encoding. 🌸
- Reregister with a DA before the Lifetime of registered service information elapses. ⏰
- If configured to use a protected scope, be able to use "md5WithRSAEncryption" [4] to produce the signed data. 🫧
21.3. Directory Agent Requirements 👑
last stop, the Directory Agent 🫶 A Directory Agent MAY:
- Accept registrations and requests in non-US-ASCII character encodings. This is encouraged, especially for UNICODE [1] and UTF-8 [24] encodings. 🌈
A Directory Agent SHOULD:
- Be able to configure certain scopes as protected scopes, so that registrations within those scopes require the calculation of cryptographically strong authenticators. This requires that the DA be able to possess the keys needed for the authentication, or that the DA be able to acquire a certificate generated by a trusted Certificate Authority [23], before completing Service Registrations for protected scopes. 🔐
A Directory Agent MUST be able to:
- Send an unsolicited DA Advertisements to the Service Location General Multicast address on startup and repeat it periodically. This reply has an XID which is incremented by one each time. If the DA starts with state, it initializes the XID to
0x0100. If it starts up stateless, it initializes the XID to0x0000. 📣 - Ignore any unauthenticated Service Registration or Service Deregistration from an entity with which it maintains a security association. 🙈
- Listen on the Directory Agent Discovery Multicast Address for Directory Agent Discovery requests. Filter these requests if the Previous Responder Address Specification list includes the DA's Address Specification. 👂
- Listen for broadcast requests to the Service Location port. 📡
- Listen on the TCP and UDP Service Location Ports for unicast requests, registrations and deregistrations and service them. 💖
- Provide a way in which scope information can be used to configure the Directory Agent. 🎀
- Expire registrations when the service registration's lifetime expires. ⏰
- When a Directory Agent has been configured with a scope, it MUST refuse all requests and registrations which do not have this scope. The DA replies with a
SCOPE_NOT_SUPPORTEDerror. There is one exception: all DAs MUST respond to DA discovery requests which have no scope. 🚫
the one exception is the main character moment: DA discovery with no scope always gets a reply 💅
- When a Directory Agent has been configured without a scope, it MUST accept ALL registrations and requests. 🌟
- Ignore any unauthenticated Service Location messages when an appropriate IPSec Security Association exists for that request. 🛡️
- Use the IP Authentication and IP Encapsulating Security Payload in Service Location messages whenever an appropriate IPSec Security Association exists. 🔒
- Accept requests and registrations in US-ASCII. 🌸
- If configured with a protected scope, be able to authenticate (at least by using "md5WithRSAEncryption" [4]) Service Registrations advertising services purporting to belong to such configured protected scopes. 🫧
22. Configurable Parameters and Default Values 🎛️✨
okay so Service Location has a bunch of config knobs, and bestie, the defaults are chosen so everything just works without you touching a single one 💅 but a site admin can absolutely pick other values. the configurable stuff is what makes this protocol actually useful across all kinds of setups 🌈
Multicast vs. Broadcast 📡
All Service Location entities must use multicast by default. The ability to use broadcast messages must be configurable for UAs and SAs. Broadcast messages are to be used in environments where not all Service Location entities have hardware or software which supports multicast.
Multicast Radius 🌸
Multicast requests should be sent to all subnets in a site. The default multicast radius for a site is 32. This value must be configurable. The value for the site's multicast TTL may be obtained from DHCP using an option which is currently unassigned.
Directory Agent Address 🧚
The Directory Agent address discovery mechanism must be configurable. There are three possibilities for this configuration: a default address, no default address, and the use of DHCP to locate a DA as described in section 15.2. The default value should be use of DHCP, with "no default address" used if DHCP does not respond. In this case the UA or SA must do a Directory Agent Discovery query.
Directory Agent Scope Assignment 🎀
The scope or scopes of a DA must be configurable. The default value for a DA is to have no scope if not otherwise configured.
Path MTU 🍓
The default path MTU is assumed to be 1400. This value may be too large for the infrastructure of some sites. For this reason this value MUST be configurable for all SAs and DAs.
Keys for Protected Scopes 🔐
If the local administration designates certain scopes as "protected scopes", the agents making use of those scopes have to be able to acquire keys to authenticate data sent by services along with their advertised URLs for services within the protected scope. For instance, service agents would use a private key to produce authentication data. By default, service agents use md5WithRSAEncryption [4] to produce the signed data, to be included with service registrations and deregistrations (see appendix B, 4.3). This authentication data could be verified by user agents and directory agents that possess the corresponding public key.
22.1. Service Agent: Use Predefined Directory Agent(s) 🦋
A Service Agent's default configuration is to do passive and active DA discovery and to register with all DAs which are properly scoped.
A Service Agent SHOULD be configurable to allow a special mode of operation: they will use only preconfigured DAs. This means they will not actively or passively detect DAs.
If a Service Agent is configured this way, knowledge of the DA must come through another channel, either static configuration or by the use of DHCP.
the availability of the Service information will not be consistent between DAs. the mechanisms which achieve eventual consistency between DAs are ignored by the SA, so their service information will not be distributed. this leaves the SA open to failure if the DA they are configured to use fails. 💀
22.2. Time Out Intervals ⏰
These values should be configurable in case the site deploying Service Location has special requirements (such as very slow links.)
Interval name Section Default Value Meaning
----------------- ------- ------------- -----------------------
CONFIG_INTERVAL_0 4.1 1 minute Cache replies by XID.
CONFIG_INTERVAL_1 4.4 10800 seconds registration Lifetime,
(ie. 3 hours)after which ad expires
CONFIG_INTERVAL_2 5 each second, Retry multicast query
backing off until no new values
gradually arrive.
CONFIG_INTERVAL_3 5 15 seconds Max time to wait for a
complete multicast query
response (all values.)
CONFIG_INTERVAL_4 9 3 seconds Wait to register on
reboot.
CONFIG_INTERVAL_5 5.2 3 seconds Retransmit DA discovery,
try it 3 times.
CONFIG_INTERVAL_6 5.2 5 seconds Give up on requests sent
to a DA.
CONFIG_INTERVAL_7 5.2 15 seconds Give up on DA discovery
CONFIG_INTERVAL_8 5.1 15 seconds Give up on requests
sent to SAs.
CONFIG_INTERVAL_9 15.2 3 hours DA Heartbeat, so that SAs
passively detect new DAs.
CONFIG_INTERVAL_10 15.2 1-3 seconds Wait to register services
on passive DA discovery.
CONFIG_INTERVAL_11 9 1-3 seconds Wait to register services
on active DA discovery.
CONFIG_INTERVAL_12 18.1 5 minutes DAs and SAs close idle
connections.A note on CONFIG_INTERVAL_9: while it might seem advantageous to have frequent heartbeats, this poses a significant risk of generating a lot of overhead traffic. This value should be kept high to prevent routine protocol operations from using any significant bandwidth. 🚫📉
23. Non-configurable Parameters 🔒
these ones are locked in, no changes allowed 🙅♀️ here's the IP port number for unicast requests to Directory Agents:
UDP and TCP Port Number: 427and the multicast addresses:
Service Location General Multicast Address: 224.0.1.22
Directory Agent Discovery Multicast Address: 224.0.1.35A range of 1024 contiguous multicast addresses for use as Service Specific Discovery Multicast Addresses will be assigned by IANA. 🦄
the error codes, iykyk:
No Error 0
LANGUAGE_NOT_SUPPORTED 1
PROTOCOL_PARSE_ERROR 2
INVALID_REGISTRATION 3
SCOPE_NOT_SUPPORTED 4
CHARSET_NOT_UNDERSTOOD 5
AUTHENTICATION_ABSENT 6
AUTHENTICATION_FAILED 724. Acknowledgments 🫶
This protocol owes some of the original ideas to other service location protocols found in many other networking protocols. Leo McLaughlin and Mike Ritter (Metricom) provided much input into early version of this document. Thanks also to Steve Deering (Xerox) for providing his insight into distributed multicast protocols. Harry Harjono and Charlie Perkins supplied the basis for the URL based wire protocol in their Resource Discovery Protocol. Thanks also to Peerlogic, Inc. for supporting this work. Lastly, thanks to Jeff Schiller for his help in shaping the security architecture specified in this document. 🌟
A. Appendix: Technical contents of ISO 639:1988 (E/F): "Code for the representation of names of languages" 🌍
Two-letter lower-case symbols are used. The Registration Authority for ISO 639 [14] is Infoterm, Osterreiches Normungsinstitut (ON), Postfach 130, A-1021 Vienna, Austria. Contains additions from ISO 639/RA Newsletter No.1/1989. See also RFC 1766.
aa Afar ga Irish mg Malagasy
ab Abkhazian gd Scots Gaelic mi Maori
af Afrikaans gl Galician mk Macedonian
am Amharic gn Guarani ml Malayalam
ar Arabic gu Gujarati mn Mongolian
as Assamese mo Moldavian
ay Aymara ha Hausa mr Marathi
az Azerbaijani he Hebrew ms Malay
hi Hindi mt Maltese
ba Bashkir hr Croatian my Burmese
be Byelorussian hu Hungarian
bg Bulgarian hy Armenian na Nauru
bh Bihari ne Nepali
bi Bislama ia Interlingua nl Dutch
bn Bengali; Bangla in Indonesian no Norwegian
bo Tibetan ie Interlingue
br Breton ik Inupiak oc Occitan
is Icelandic om (Afan) Oromo
ca Catalan it Italian or Oriya
co Corsican ja Japanese
cs Czech jw Javanese pa Punjabi
cy Welsh pl Polish
ka Georgian ps Pashto, Pushto
da Danish kk Kazakh pt Portuguese
de German kl Greenlandic
dz Bhutani km Cambodian qu Quechua
rw Kinyarwanda
el Greek kn Kannada rm Rhaeto-Romance
en English ko Korean rn Kirundi
eo Esperanto ks Kashmiri ro Romanian
es Spanish ku Kurdish ru Russian
et Estonian ky Kirghiz
eu Basque
la Latin
fa Persian ln Lingala
fi Finnish lo Laothian
fj Fiji lt Lithuanian
fo Faeroese lv Latvian, Lettish
fr French
fy Frisian
sa Sanskrit ta Tamil ug Uigar
sd Sindhi te Telugu uk Ukrainian
sg Sangro tg Tajik ur Urdu
sh Serbo-Croatian th Thai uz Uzbek
si Singhalese ti Tigrinya
sk Slovak tk Turkmen vi Vietnamese
sl Slovenian tl Tagalog vo Volapuk
sm Samoan tn Setswana
sn Shona to Tonga wo Wolof
so Somali tr Turkish
sq Albanian ts Tsonga xh Xhosa
sr Serbian tt Tatar
ss Siswati tw Twi yi Yiddish
st Sesotho yo Yoruba
su Sundanese
sv Swedish za Zhuang
sw Swahili zh Chinese
zu Zuluthat's the end of this bit, bestie 🧚 the 14th part of the RFC is done, slay!
B. SLP Certificates ✨
okay so certificates can be used in SLP to hand out the public keys of trusted protected scopes 🔐 this appendix is all about how that works, assuming you already have the public keys 💅
bestie, having the private key of a protected scope is literally the same as being a trusted SA 👑 so the whole scope is only as trustworthy as those private keys being held by trusted hosts, and only ever used for legit service registrations and deregistrations. no cap, guard those keys like your diary 🔒
if you can reach the proper Certificate Authority (CA), then DAs and UAs don't have to hold the public keys for these protected scopes ahead of time 🦋 what they do need is the CA's public key. the CA makes certificates using its own unique private key, and that private key is not shared with any other system and must remain secure. the certificates say that a given protected scope has a given public key, plus when the certificate expires ⏳
the ASCII (mail-safe) version of a certificate is a list of tag and value pairs, and it looks like this 🎀
"certificate-alg=" 1*ASN1CHAR CRLF
"scope-charset=" 1*DIGIT CRLF
"scope=" 1*RADIX-64-CHAR CRLF
"timestamp=" 16HEXDIGIT CRLF
"public-key=" 1*RADIX-64-CHAR CRLF
"cert-digest=" 1*RADIX-64-CHAR CRLF
ASN1CHAR = DIGIT | '.'
HEXDIGIT = DIGIT | 'a'..'f' | 'A'..'F'
RADIX-64-CHAR = DIGIT | 'a'..'z' | 'A'..'Z' | '+' | '/' | '='the radix-64 notation is described in RFC 1521 [7] 🌸 spaces get ignored when you compute the binary value of a Radix-64 string, and if the value for scope, public-key or cert-digest is longer than 72 characters, it can be broken up over separate lines. those continuation lines have to start with one or more spaces. only the tags listed above are allowed to start in the first column of the certificate string 🙈 this is what clears up the parsing ambiguity, since the tags themselves are legal Radix-64 values (so you'd otherwise have no way to tell them apart, iykyk)
certificate-alg is the ASN.1 string for the Object Identifier value of the algorithm used to produce the "cert-digest" 🧚 scope-charset is a decimal representation of the MIBEnum value for the character set the scope is written in.
because the scope gets radix-64 encoded, you can get an ASCII rendering of a scope string in any character set at all ✨ literally so iconic.
the 8 byte NTP format timestamp is written as 16 hex digits, and it's the time when the certificate will expire ⏰
the format of the public key depends on the kind of cryptosystem being used, and that's identified by certificate-alg 💜 when the CA generated the certificate holding the public key, it used the message digest algorithm named in certificate-alg to calculate a digest D over the string encoding of the certificate, leaving out the cert-digest. then the CA encrypted that value with the CA's private key to make the cert-digest, which goes into the certificate 🔥
the CA generates certificates off-line 🌙 SLP doesn't specify how certificates get distributed, though it might in the future. the CA picks the algorithms for the message digest and for public key decryption. a DA or SA only needs to get the certificate, have a preconfigured public key for the CA, and support the algorithm named in certificate-alg, and then it can get certified new public keys for protected scopes 🫶
a DA or UA can confirm a certificate by calculating the message digest D with the message digest algorithm named in certificate-alg. the input is the string encoding of the certificate, leaving out the cert-digest. then the cert-digest gets decrypted with the CA's public key to produce D'. if D is the same as D', the certificate is legit 💖 the public-key for the protected scope can be used until the expiration date in the certificate timestamp.
the certificate can be sent over untrusted channels like email or file transfer, because it has to be verified anyway 📬 but the CA's public key must be delivered over a trusted channel, no exceptions 🔐
C. Example of deploying SLP security using MD5 and RSA 🔐
let's say our site has a protected scope called "CONTROLLED" 🎀 we generate a private key and public key pair for the scope using RSA. all the SAs in the protected scope keep the private key on a secret key ring. the public key is available to all the DAs that support the protected scope and to all the UAs that are going to use it 💅
to register or deregister a URL, the data that needs authenticating (as described in section 4.3) gets digestified with MD5 [22] to create a digital signature, and then that gets encrypted with RSA using the protected scope's private key 🦋 the output of RSA goes into the authenticator data field of the authenticator block.
the DA or UA figures out how to verify the authentication by looking inside the authentication block 👀 say the "md5WithRSAEncryption" [4] algorithm has to be used to verify the signed data. the DA or UA calculates the message digest of the URL Entry using md5, exactly the way the SA did it. then the authenticator block gets decrypted with the public key for the "CONTROLLED" scope, which lives in the public key ring of the UA or DA under the name "CONTROLLED" 🌈 if the digest the UA or DA calculated matches the SA's, the URL Entry has been validated ✨
D. Example of use of SLP Certificates by mobile nodes 📱
say a mobile node needs to use protected scopes 🧚 the mobile node gets preconfigured by adding a single public key to its public key ring. we'll call it the CA-Key 🗝️ this key is used to get SLP certificates in the format described in Appendix B. the matching private key is what the CA uses to make the certificates in the right format.
the CA might be run by a system administrator on a computer that isn't connected to any networks 🙈 how long a certificate lasts depends on the site's policy. the duration, scope, and public key for the protected scope are used as input to 'md5sum' 💜 that sum gets encrypted with RSA using the CA's private key. the radix 64 encoding of that gets added to the mail-safe string based certificate encoding from Appendix B 🍓
the certificate, say for the protected scope "CONTROLLED", could be made available to the mobile node. for example, it might be on a web page 🌸 the mobile node can then process the certificate to get the public key for the CONTROLLED scope. there's still no reason to trust this key is really the one to use (same as in Appendix C) 😭 to trust it, calculate the md5 checksum of the ascii encoded certificate, leaving out the cert-digest. next, decrypt the cert-digest using the CA's public key and RSA. if the cert-digest matches the output of MD5, the certificate may be trusted (until it expires) 💖
so the mobile node only needs one key (CA-key) to dynamically get the others and use protected scopes 👑 notice that we do not define any method for access control by arbitrary UAs to SAs in protected scopes. that part is totally up to you, bestie 🫶
E. Appendix: For Further Reading 📚
three related resource discovery protocols are NBP and ZIP, which are part of the AppleTalk protocol family [12], the Legato Resource Administration Platform [25], and the Xerox Clearinghouse system [20] 🦋 domain names and the representation of addresses get used a LOT in the Service Location Protocol, and the references for those are RFCs 1034 and 1035 [17, 18] 🌈 for router discovery protocols, examples include Router Discovery [10] and Neighbor Discovery [19] 🧚
References 📖
[1] Unicode Technical Report #4. The unicode standard, version 1.1
(volumes 1 and 2). Technical Report (ISBN 0-201-56788-1) and
(ISBN 0-201-60845-6), Unicode Consortium, 1994.
[2] Alexander, S. and R. Droms. DHCP Options and BOOTP Vendor
Extensions. RFC 2131, March 1997.
[3] Atkinson, R. IP Encapsulating Security Payload. RFC 1827,
August 1995.
[4] Balenson, D. Privacy Enhancement for Internet Electronic
Mail: Part III: Algorithms, Modes, and Identifiers. RFC 1423,
February 1993.
[5] Berners-Lee, T. and D. Connolly. Hypertext Markup Language -
2.0. RFC 1866, November 1995.
[6] Berners-Lee, T., L. Masinter, and M. McCahill. Uniform Resource
Locators (URL). RFC 1738, December 1994.
[7] Borenstein, N. and N. Freed. MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies. RFC 2045, November 1996.
[8] Bradner, Scott. Key words for use in RFCs to Indicate
Requirement Levels. BCP 14, RFC 2119, March 1997.
[9] CCITT. Specification of the Abstract Syntax Notation One
(ASN.1). Recommendation X.208, 1988.
[10] Deering, Stephen E., editor. ICMP Router Discovery Messages.
RFC 1256, September 1991.
[11] Droms, Ralph. Dynamic Host Configuration Protocol. RFC 2131,
March 1997.
[12] Gursharan, S., R. Andrews, and A. Oppenheimer. Inside
AppleTalk. Addison-Wesley, 1990.
[13] Guttman, E. The service: URL scheme, November 1996.
Work In Progress.
[14] Geneva ISO. Code for the representation of names of languages.
ISO 639:1988 (E/F), 1988.
[15] ISO 8879, Geneva. Information Processing -- Text and Office
Systems - Standard Generalized Markup Language (SGML).
<URL:http://www.iso.ch/cate/d16387.html>, 1986.
[16] Mills, D. Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI. RFC 2030, October 1996.
[17] Mockapetris, P. Domain Names - Concepts and Facilities. STD 13,
RFC 1034, November 1987.
[18] Mockapetris, P. DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION. STD 13, RFC 1035, November 1987.
[19] Narten, T., E. Nordmark, and W. Simpson. Neighbor Discovery for
IP version 6 (IPv6). RFC 1970, August 1996.
[20] Oppen, D. and Y. Dalal. The clearinghouse: A decentralized
agent for locating named objects in a distributed environment.
Technical Report Tech. Rep. OPD-78103, Xerox Office Products
Division, 1981.
[21] Perkins, C. DHCP Options for Service Location Protocol, August
1996. Work In Progress.
[22] Rivest, Ronald. The MD5 Message-Digest Algorithm. RFC 1321,
April 1992.
[23] Schneier, Bruce. Applied Cryptography: Protocols, Algorithms,
and Source Code in C. John Wiley, New York, NY, USA, 1994.
[24] X/Open Preliminary Specification. File System Safe UCS
Transformation Format (FSS_UTF). Technical Report Document
Number: P316, X/Open Company Ltd., 1994.
[25] Legato Systems. The Legato Resource Administration Platform.
Legato Systems, 1991.Authors' Addresses 💌
okay bestie, if you have questions about this memo, these are the people to ask 🫶 the whole crew wrote it, so here's how to reach each of them 🧚
John Veizades Erik Guttman
@Home Network Sun Microsystems
385 Ravendale Dr. Gaisbergstr. 6
Mountain View, CA 94043 69115 Heidelberg Germany
Phone: +1 415 944 7332 Phone: +1 415 336 6697
Fax: +1 415 944 8500
Email: veizades@home.com Email: Erik.Guttman@eng.sun.com
Charles E. Perkins Scott Kaplan
Sun Microsystems
2550 Garcia Avenue 346 Fair Oaks St.
Mountain View, CA 94043 San Francisco, CA 94110
Phone: +1 415 336 7153 Phone: +1 415 285 4526
Fax: +1 415 336 0670
EMail: cperkins@Corp.sun.com Email: scott@catch22.comthat's the whole crew 💖 five authors, and you've got their contact details right here 🌸
📦 where this page comes from
- ietf: rfc2165 1997-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms