Service Templates and Service: Schemes

Abstract service types SHOULD be used when a service can be accessed via multiple protocols (e.g., 'device-drivers' via ftp, tftp, or http) rather than encoding a concrete protocol name as the service type. This allows SLP queries for the abstract type to return all protocol variants, letting the client select the most appropriate one.

Attribute identifiers are restricted to URL-unreserved characters because services may display prominent attributes directly in their service: URL registrations. Translation of attribute identifiers is explicitly prohibited because they can be embedded in URLs or program code, analogous to variable identifiers.

Attributes are typically stored and retrieved separately from the service: URL using SLP rather than embedded in the URL. Only attributes required to access a particular service (such as an authentication mechanism) are included in the service: URL itself, keeping URLs compact while supporting rich service description.

Version numbering follows major.minor semantics: adding optional attributes increments only the minor version (backward compatible — a 1.x client can use 1.y where x<y by ignoring unknown attributes), while adding required attributes, removing attributes, or changing definitions increments the major version (incompatible change).

For SLPv1 compatibility: abstract service types must not be used (SLPv1 does not support them); opaque values must be converted from '\FF' hex notation to radix-64; escape characters must use HTML convention '&#DIGIT;' rather than '\' HEXDIG HEXDIG.

The template-type, template-version, template-description, and template-url-syntax items are defined as SLPv2 attributes and MAY accompany any service registration, enabling a recipient to discover exactly which template version was used to register the service.

Translation between template languages requires the same ordered attribute definitions across language versions. Non-literal attribute identifiers, type names, flags, and boolean constants 'true'/'false' are never translated; only attribute values and descriptive help text are translatable. A 'localize-<tag>' attribute naming convention is suggested for localizing attribute identifier display names.

Clients SHOULD include attributes marked with the 'x' flag in requests for services; neglecting to include this attribute will not sufficiently differentiate the service and may result in obtaining useless services.

Concrete service templates MUST NOT redefine attributes already defined in the abstract service template from which they are derived; all abstract attributes are implicitly inherited by the concrete template.

Each Service Template submitted to IANA MUST include a security considerations section describing security issues specific to using the service scheme for that service type.

security, registry

If an optional attribute's definition includes an allowed values list, a default value or list is required (not optional), ensuring the default is always a member of the allowed set. Translations of default and allowed value lists MUST maintain their original order.

If the service type name denotes a particular protocol, the service type name SHOULD either be assigned the name of a well-known port by convention or be the Assigned Numbers name for the service.

Keyword attribute definitions MUST have no flag information, no default values list, and no allowed values list. Boolean attributes are single-value only — multi-valued boolean attributes are not allowed.

New service type templates submitted for standardization MUST set 'template-version' to 0.0. Templates below version 1.0 are not submitted to IANA; the template is reissued at 1.0 once consensus is achieved.

registry

No service type template will be accepted for inclusion in the IANA registry unless the submission includes a security considerations section and contact information for the template document author.

registry, security

Reserved characters (';', '%', '=', ',', '#', LF, CR) MUST be escaped in service template documents. String matching SHOULD be case insensitive after decoding character escapes and trimming whitespace.

The abstract service type MUST be well specified, providing either an access protocol with network address or an embedded URL for a standardized scheme that fully describes how to access the service.

The service template submission MUST follow a specified format including: Name of submitter, Language of service template, Security Considerations, and Template Text delimited by 'template begins here' / 'template ends here' markers to allow trivial cut-and-paste extraction.

registry

The syntax for the <url-path> field MUST accompany the definition of a new service type unless the URL scheme has already been standardized and is not a service: URL. Abstract service types may defer this to their concrete instance templates.

The syntax of a service: URL MUST conform to an 'absolute URI' as defined by RFC 2396. Service type names are case-folded to lower case; 'http' and 'HTTP' designate the same service type.

The template used for standardization MUST be encoded in the 0x00–0x7F subrange of UTF-8 (ASCII) and be in English. All characters outside the ASCII range MUST be escaped using '\' HEXDIG HEXDIG syntax.

A service template has four required identification items: template-type (service type name and optional naming authority), template-version (major.minor version number), template-description (human-readable text), and template-url-syntax (ABNF for the url-path production). These are followed by zero or more attribute definitions, each terminated by a blank line.

Attribute flags follow the type on the same line and may appear in any order: 'o'/'O' (optional; absence means required), 'm'/'M' (multi-valued unordered set; deletions of individual values not supported), 'l'/'L' (literal; not to be translated), 'x'/'X' (clients SHOULD include this attribute in service requests to differentiate the service).

Attributes can be one of five types: string (UTF-8, set determined at registration time), integer (signed 32-bit), boolean (single-valued only), opaque ('\FF' followed by hex-encoded bytes), or keyword (existence-only attribute with no type, flags, or values). Each attribute identifier must be unique within a template and is case-folded.

IANA maintains a registry of service type templates, including both the templates themselves and all previous versions, keyed by naming convention '<service-type>.<version-no>.<langtag>'. Submissions are reviewed by a Designated Expert appointed by the IESG and require a security considerations section and author contact information.

registry

If service type templates are modified or false templates are distributed, services may register incorrectly or clients may misinterpret service information. Service: URLs could be distributed to redirect clients to incorrect services; SLPv2 provides an authentication mechanism allowing registered service: URLs to be signed and verified.

security

String values in templates are sequences of non-whitespace tokens potentially with embedded whitespace; interior runs of whitespace are collapsed to a single space and leading/trailing whitespace is removed. Value lists are comma-separated; a line ending with a comma continues onto the next line.

The service: URL ABNF defines fields: service-type (abstract-type ':' url-scheme or concrete-type), sap (site + url-part), where site supports ipsite (IP/DNS with '//' prefix), ipxsite (IPX: 8-hex network, 12-hex node, 4-hex socket), and atsite (AppleTalk: 1–31 AppleAscii chars each for object, type, zone). The url-part contains optional url-path and attr-list of semicolon-separated attribute assignments.