diff options
Diffstat (limited to 'doc/rfc/rfc2609.txt')
| -rw-r--r-- | doc/rfc/rfc2609.txt | 1851 |
1 files changed, 1851 insertions, 0 deletions
diff --git a/doc/rfc/rfc2609.txt b/doc/rfc/rfc2609.txt new file mode 100644 index 0000000..25d2ed9 --- /dev/null +++ b/doc/rfc/rfc2609.txt @@ -0,0 +1,1851 @@ + + + + + + +Network Working Group E. Guttman +Request for Comments: 2609 C. Perkins +Updates: 2165 J. Kempf +Category: Standards Track Sun Microsystems + June 1999 + + + Service Templates and Service: Schemes + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Abstract + + The "service:" URL scheme name is used to define URLs (called + "service: URLs" in this document) that are primarily intended to be + used by the Service Location Protocol in order to distribute service + access information. These schemes provide an extensible framework + for client-based network software to obtain configuration information + required to make use of network services. When registering a + service: URL, the URL is accompanied by a set of well-defined + attributes which define the service. These attributes convey + configuration information to client software, or service + characteristics meaningful to end users. + + This document describes a formal procedure for defining and + standardizing new service types and attributes for use with the + "service:" scheme. The formal descriptions of service types and + attributes are templates that are human and machine understandable. + They SHOULD be used by administrative tools to parse service + registration information and by client applications to provide + localized translations of service attribute strings. + + + + + + + + + + +Guttman, et al. Standards Track [Page 1] + +RFC 2609 Service Templates and URLs June 1999 + + +Table of Contents + + 1. Introduction 2 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Service Location Protocol . . . . . . . . . . . . . . 5 + 1.2.1. Compatibility with SLPv1 . . . . . . . . . . . 5 + 2. Service URL Syntax and Semantics 5 + 2.1. Service URL Syntax . . . . . . . . . . . . . . . . . 5 + 2.2. Service URL Semantics . . . . . . . . . . . . . . . . 8 + 2.3. Use of service: URLs . . . . . . . . . . . . . . . . 9 + 2.4. Specifying the Service Type-Specific URL Syntax. . . . 10 + 2.5. Accommodating Abstract Service Types . . . . . . . . 10 + 2.5.1. Advertising Abstract Service Types . . . . . . 11 + 3. Syntax and Semantics of Service Type Specifications 12 + 3.1. Syntax of Service Type Templates . . . . . . . . . . 12 + 3.2. Semantics of Service Type Templates. . . . . . . . . . 15 + 3.2.1. Definition of a Service Template . . . . . . . 15 + 3.2.2. Service Type . . . . . . . . . . . . . . . . . 16 + 3.2.3. Version Number . . . . . . . . . . . . . . . . 16 + 3.2.4. Description . . . . . . . . . . . . . . . . . 16 + 3.2.5. Syntax of the Service Type-specific URL Part . 17 + 3.2.6. Attribute Definition . . . . . . . . . . . . 17 + 4. A Process For Standardizing New Service Types 21 + 5. IANA Considerations 22 + 6. Internationalization Considerations 24 + 6.1. Language Identification and Translation. . . . . . . . 24 + 7. Security Considerations 25 + A. Service Template Examples 26 + A.1. FOO . . . . . . . . . . . . . . . . . .. . . . . . . . 26 + A.2. Abstract Service Type: Net-Transducer . . . . . . . . 28 + A.3. Concrete Service Type: Net-Transducer:Thermometer . . 29 + A.4. service: URLs and SLP . . . . . . . . . . . . . . . . 30 + B. Acknowledgments 30 + C. References 31 + D. Authors' Addresses 32 + E. Full Copyright Statement 33 + +1. Introduction + + This document describes a URL scheme, called service: URL, which + defines network access information for network services using a + formal notation. In addition it describes how to define a set of + attributes to associate with a service: URL. These attributes will + allow end users and programs to select between network services of + the same type that have different capabilities. The attributes are + defined in a template document that is readable by people and + machines. + + + + +Guttman, et al. Standards Track [Page 2] + +RFC 2609 Service Templates and URLs June 1999 + + + A client uses attributes to select a particular service. Service + selection occurs by obtaining the service: URL that offers the right + configuration for the client. Service type templates define the + syntax of service: URLs for a particular service type, as well as the + attributes which accompany a service: URL in a service registration. + + Templates are used for the following distinct purposes: + + 1. Standardization + + The template is reviewed before it is standardized. Once it is + standardized, all versions of the template are archived by IANA. + + 2. Service Registration + + Servers making use of the Service Location Protocol [10] register + themselves and their attributes. They use the templates to + generate the service registrations. In registering, the service + must use the specified values for its attributes. + + 3. Client presentation of Service Information + + Client applications may display service information. The + template provides type information and explanatory text which may + be helpful in producing user interfaces. + + 4. Internationalization + + Entities with access to the template for a given service type in + two different languages may translate between the two languages. + + A service may register itself in more than one language using + templates, though it has been configured by an operator who + registered service attributes in a single language. + + All grammar encoding follows the Augmented BNF (ABNF) [8] for syntax + specifications. + +1.1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [6]. + + + + + + + + +Guttman, et al. Standards Track [Page 3] + +RFC 2609 Service Templates and URLs June 1999 + + + The following terminology is used for describing service: URLs. + + service scheme + + A URL scheme whose name starts with the string "service:" and + is followed by the service type name, constructed according to + the rules in this document. + + service: URL + + A URL constructed according to the service scheme definition. + It typically provides at least the following: The name of an + access protocol, and an address locating this service. The + service: URL may include url path information specific to the + type of service, as well as attribute information encoded + according to the URL grammar. The service: URL is used by the + Service Location Protocol to register and discover the location + of services. It may be used by other protocols and in + documents as well. + + service type + + A name identifying the semantics by which the remainder of the + service: URL is to be understood. It may denote either a + particular network protocol, or an abstract service associated + with a variety of protocols. If the service type denotes a + particular protocol, then the service type name SHOULD either + be assigned the name of a particular well known port [2] by + convention or be the Assigned Numbers name for the service [1]. + + abstract service type + + A service type name which is associated with a variety of + different protocols. An example is given in Section A. + Section 2 discusses various ways that abstract types can be + accommodated. + + service registration + + A service: URL and optionally a set of attributes comprise a + service registration. This registration is made by or on + behalf of a given service. The URL syntax and attributes must + conform to the service template for the registered service. + + service template + + A formal description of the service attributes and service + scheme associated with a particular service type. + + + +Guttman, et al. Standards Track [Page 4] + +RFC 2609 Service Templates and URLs June 1999 + + +1.2. Service Location Protocol + + The Service Location Protocol version 2 [10] allows service: URLs to + be registered and discovered, though service: URLs may be also used + in other contexts. + + Client applications discover service registrations by issuing queries + for services of a particular type, specifying the attributes of the + service: URLs to return. Clients retrieve the attributes of a + particular service by supplying its service: URL. Attributes for all + service registrations of a particular type can also be retrieved. + + Services may register themselves, or registrations may be made on + their behalf. These registrations contain a service: URL, and + possibly attributes and digital signatures. + +1.2.1. Compatibility with SLPv1 + + This document adopts the encoding conventions of SLPv2. + + Compatibility with SLPv1 [[15]] is possible, if the following + conventions are observed: + + 1. Abstract service types must not be used. SLPv2 specifies the + use of Service URLs with abstract service types. SLPv1 does not + support them. Thus, a service template which is to serve both + SLPv1 and SLPv2 must not use abstract service types. + + 2. The syntax for representing opaque values in this document is + consistent with SLPv2. The syntax must be converted for use with + SLPv1. Instead of a sequence of "\FF" then "\" HEXDIG HEXDIG for + each byte in the opaque value, SLPv1 uses radix-64 notation. + + 3. Escape characters are significantly differently in SLPv1 and + SLPv2. Instead of using escaped byte notation for escaped + characters, SLPv1 uses the HTML convention `&' `#' 1*DIGIT `;'. + +2. Service URL Syntax and Semantics + + This section describes the syntax and semantics of service: URLs. + +2.1. Service URL Syntax + + The syntax of the service: URL MUST conform to an 'absolute URI' as + defined by [5]. The syntax of a service: URL differs enough from a + 'generic URI' that it is best to treat it as an opaque URI unless a + specific parser for the service: URL is available. + + + + +Guttman, et al. Standards Track [Page 5] + +RFC 2609 Service Templates and URLs June 1999 + + + All service: URLs have the same syntax up to the 'url-part' The + syntax for a service URL depends on the service type following the + service scheme. All service: URLs have a service access point + portion, indicating the address of the service to access. + + The syntax for the <sap> field depends upon the service type + definition. The <sap> field is the service access point, and + describes how to access the service. In addition, although both + upper case and lower case characters are recognized in the <service- + type> field for convenience, the name is case-folded into lower case. + Service types are therefore not distinguished on the basis of case, + so, for example, "http" and "HTTP" designate the same service type. + This is consistent with general URL practice, as outlined in [5]. + + The ABNF for a service: URL is: + + service: URL = "service:" service-type ":" sap + service-type = abstract-type ":" url-scheme / concrete-type + abstract-type = type-name [ "." naming-auth ] + concrete-type = protocol [ "." naming-auth ] + type-name = resname + naming-auth = resname + url-scheme = resname + ; A recognized URL scheme name, standardized + ; either through common practice or through + ; approval of a standards body. + resname = ALPHA [ 1*(ALPHA / DIGIT / "+" / "-") ] + sap = site [url-part] + site = ipsite / atsite / ipxsite + ipsite = "//" [ [ user "@" ] hostport ] + hostport = host [ ":" port ] + host = hostname / hostnumber + hostname = *( domainlabel "." ) toplabel + alphanum = ALPHA / DIGIT + domainlabel = alphanum / alphanum *[alphanum / "-"] alphanum + toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum + hostnumber = ipv4-number + ipv4-number = 1*3DIGIT 3("." 1*3DIGIT) + port = 1*DIGIT + ; A port number must be included if the + ; protocol field does not have an IANA + ; assigned port number. + user = *[ uchar / ";" / "+" / "&" / "=" ] + ipxsite = "/ipx/" ipx-net ":" ipx-node ":" ipx-socket + ipx-net = 8 HEXDIGIT + ipx-node = 12 HEXDIGIT + ipx-socket = 4 HEXDIGIT + atsite = "/at/" at-object ":" at-type "" at-zone + + + +Guttman, et al. Standards Track [Page 6] + +RFC 2609 Service Templates and URLs June 1999 + + + at-object = 1*31apple-char + at-type = 1*31apple-char + at-zone = 1*31apple-char + apple-char = ALPHA / DIGIT / safe / escaped + = ; AppleAscii [7] values that are not + = ; from the restricted range must be escaped. + = ; NOTE: The escaped values do NOT correspond + = ; to UTF-8 values here: They are AppleAscii + = ; bytes. + url-part = [ url-path ] [ attr-list ] + url-path = 1 * ( "/" *xchar ) + ; Each service type must define its + ; own syntax consistent + ; with [5]. + attr-list = 1 * ( ";" attr-asgn ) + attr-asgn = attr-id / attr-id "=" attr-value + safe = "$" / "-" / "_" / "." / "~" + extra = "!" / "*" / "'" / "(" / ")" / "," / "+" + uchar = unreserved / escaped + xchar = unreserved / reserved / escaped + escaped = 1*(`\' HEXDIG HEXDIG) + reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" + unreserved = ALPHA / DIGIT / safe / extra + + IPX addresses [14] are composed of a network, node and socket number. + The IPX network number is a four-byte number, in network order and + expressed in hexadecimal, that signifies an IPX subnet. The node + element represents a network interface card. It is a six-byte + number, expressed in hexadecimal, that is usually the same as the + node ID of the interface card. The socket element represents a + specific service access point, given an IPX network and node. IPX + sockets are analogous to TCP/IP ports, and are not to be confused + with Berkeley sockets. + + AppleTalk addresses [9] are composed of an object, type and zone. + The object is a human readable string. The type is an identifier, + not intended for human readability. The zone refers to the AppleTalk + Zone name, which is also human readable. The characters composing + these names are drawn from the AppleAscii character set [7]. Thus, + they do not equate to escaped ASCII or UTF-8 characters. The + characters "=" and "*" are reserved and may not be included in the + names even in binary form. + + In cases besides the AppleTalk grammar, some characters must be + escaped before use. To escape any character, precede the two digits + indicating its ASCII value by '%'. + + + + + +Guttman, et al. Standards Track [Page 7] + +RFC 2609 Service Templates and URLs June 1999 + + +2.2. Service URL Semantics + + The service scheme-specific information following the "service:" URL + scheme identifier provides information necessary to access the + service. As described in the previous subsection, the form of a + service: URL is as follows: + + service: URL = "service:" service-type ":" site url-path + + where <site> has one of the following forms could refer to an + <ipsite>, <ipxsite> or <atsite> if the service URL locates to an IP, + IPX or AppleTalk service access point, respectively. + + As discussed in Section 1, the <service-type> can be either a + concrete protocol name, or an abstract type name. + + The <ipsite> field is typically either a domain name (DNS) or an IP + network protocol address for the service, and possibly a port number. + Note that use of DNS hostnames is preferred for ease of renumbering. + The <site> field can be null if other information in the service URL + or service attributes is sufficient to use the service. + + The <sap> field allows more information to be provided (by way of + <url-path> and <attr-list>) that can uniquely locate the service or + resource if the <site> is not sufficient for that purpose. For IP + addresses, the <site> field begins with "//". Other address families + supported are IPX [14] and AppleTalk [9]. + + An <attr-list> field appears at the end of the <url-part> field, but + is never required to exist in any service location registration. + + The <attr-list> field is composed of a list of semicolon (";") + separated attribute assignments of the form: + + attr-id "=" attr-value + + or for keyword attributes: + + attr-id + + Attributes are part of service: URLs when the attributes are required + to access a particular service. For instance, an ACAP [13] service + might require that the client authenticate with it through Kerberos. + Including an attribute in the service registration allows the ACAP + client to make use of the correct SASL [11] authentication mechanism. + The ACAP server's registration might look like: + + service:acap://some.where.net;authentication=KERBEROSV4 + + + +Guttman, et al. Standards Track [Page 8] + +RFC 2609 Service Templates and URLs June 1999 + + + Note that there can be other attributes of an ACAP server which are + not appropriate to include in the URL. For instance, the list of + users who have access to the server is useful for selecting an ACAP + server, but is not required for a client to use the registered + service. + + Attributes associated with the service: URL are not typically + included in the service: URL. They are stored and retrieved using + other mechanisms. The service: URL is uniquely identified with a + particular service agent or resource, and is used when registering or + requesting the attribute information. The Service Location Protocol + specifies how such information is registered by network services and + obtained by client software. + +2.3. Use of service: URLs + + The service: URL is intended to allow arbitrary client/server and + peer to peer systems to make use of a standardized dynamic service + access point discovery mechanism. + + It is intended that service: URLs be selected according to the + suitability of associated attributes. A client application can + obtain the URLs of several services of the same type and distinguish + the most preferable among them by means of their attributes. The + client uses the service: URL to communicate directly to a service. + + Attributes are specified with a formal service template syntax + described in Section 3. If a service: URL registration includes + attributes, the registering agent SHOULD also keep track of the + attributes which characterize the service. + + Registrations can be checked against the formal attribute + specification defined in the template by the client or agent + representing the client. Service registration are typically done + using the Service Location Protocol [10] (SLP). SLP provides a + mechanism for service: URLs to be obtained dynamically, according to + the service's attributes. + + It is also possible to obtain service: URLs from documents and using + other protocols. In this case, the URL may not be accompanied by the + service attributes. The context in which the URL appears should make + it clear, if possible, when the service is appropriate to use. For + example, in a mail message, a service might be recommended for use + when the user is in a branch office. Or, an HTML document might + include a service: URL as a pointer to a service, describing in text + what the service does and who is authorized to use it. + + + + + +Guttman, et al. Standards Track [Page 9] + +RFC 2609 Service Templates and URLs June 1999 + + +2.4. Specifying the Service Type-Specific URL Syntax + + When a service type is specified, the specification includes the + definition of the syntax for all URLs that are registered by services + of that particular type. For instance, the "lpr" service type may be + defined with service: URLs in the following form: + + service:printer:lpr://<address of printer>/<queue name> + + The section of the URL after the address of the printer: + + "/" <queue name> + + is specific to the lpr service type and corresponds to the <url-path> + field of the general service: URL syntax. This part is specified + when the lpr service type is specified. + +2.5. Accommodating Abstract Service Types + + An abstract service type is a service type that can be implemented by + a variety of different service agents. + + In order to register a service: URL for an abstract service type the + 'abstract-type' grammar rule described in section 3.1 is used. This + will result in a URL which includes enough information to use the + service, namely, the protocol, address and path information. Unlike + 'concrete' service: URLs, however, the service type is not enough to + determine the service access. Rather, an abstract service type + denotes a class of service types. The following subsection discusses + this point in more detail. + + Concrete service templates inherit all attributes defined in the + abstract service template from which the concrete service template + was derived. Attribute defined in the abstract service template MUST + not be defined in the concrete service template as well. This + simplifies interpretation of templates. + + For example, if an abstract service template for service type ' + Abstract' defines an attribute FOO, all concrete service templates + derived from the abstract service template, such as ' + Abstract:Concrete' will implicitly include the definition of + attribute FOO. This derived template MUST NOT redefine FOO, according + to the rule above. + + A further example is described in Section A. + + + + + + +Guttman, et al. Standards Track [Page 10] + +RFC 2609 Service Templates and URLs June 1999 + + +2.5.1. Advertising Abstract Service Types + + Some services may make use of several protocols that are in common + use and are distinct services in their own right. In these cases an + abstract service type is appropriate. What is essential is that all + the required information for the service is clearly defined. + + For example, suppose a network service is being developed for + dynamically loading device drivers. The client requires the + following three pieces of information before it can successfully load + and instantiate the driver: + + 1. The protocol used to load the driver code, for example, "ftp", + "http" or "tftp" + + 2. A pathname identifying where the driver code is located, for + example "/systemhost/drivers/diskdrivers.drv", + + 3. The name of the driver, for example, "scsi". + + The temptation is to form the first two items into a URL and embed + that into a service: URL. As an example which should be avoided, + + service:ftp:/x3.bean.org/drivers/diskdrivers.drv;driver=scsi + + is a service: URL which seems to indicate where to obtain the driver. + + Rather, an abstract service-type SHOULD be used. The service type is + not "ftp", as the example indicates. Rather, it is "device-drivers". + The service: URL that should be used, consistent with the rules in + section [6], is the following: + + service:device-drivers:ftp://x3.bean.org/drivers/diskdrivers.drv; + driver=scsi;platform=sys3.2-rs3000 + + Other URLs for the same service using other protocols are also + supported, as in: + + service:device-drivers:tftp://x2.bean.org/vol3/disk/drivers.drv; + driver=scsi;platform=sys3.2-rs3000 + + service:device-drivers:http://www.bean.org/drivers/drivpak.drv; + driver=scsi;platform=sys3.2-rs3000 + + Using SLP, a search for the service type "device-drivers" may return + all of the three URLs listed above. The client selects the most + appropriate access protocol for the desired resource. + + + + +Guttman, et al. Standards Track [Page 11] + +RFC 2609 Service Templates and URLs June 1999 + + + The fundamental requirement is that the abstract service type MUST be + well specified. This requirement is imposed so that program code or + human users have enough information to access the service. In every + case, a well-specified abstract type will include either an access + protocol and a network address where the service is available, or an + embedded URL for a standardized URL scheme that describes how to + access the service. In the example above, there are three further + requirements: A URL path is included for access protocols indicating + the document to download, and two attributes are included to + characterize the driver. + +3. Syntax and Semantics of Service Type Specifications + + Service type specifications are documents in a formal syntax defining + properties important to service registration. These properties are: + + 1. General information on the service type specification itself, + + 2. The syntax of the service type-specific part of the service URL, + + 3. The definition of attributes associated with a service. + + The service type specification document is the service type template. + + The following subsections describe the syntax and semantics of + service type templates. + +3.1. Syntax of Service Type Templates + + Service template documents are encoded in a simple form. They may be + translated into any language or character set, but the template used + for standardization MUST be encoded in the 0x00-0x7F subrange of + UTF-8 [16] (which corresponds to ASCII character encoding) and be in + English. + + A template document begins with a block of text assigning values to + five document identification items. The five identification items + can appear in any order within the block, but conventionally the + "template-type" item, which assigns the service type name, occurs at + the very top of the document in order to provide context for the rest + of the document. The attribute definition item occurs after the + document identification items. + + All items end with a blank line. The reserved characters are ";", + "%", "=", ",", "#", LF, and CR. Reserved characters MUST be escaped. + The escape sequence is the same as described in [5]. + + + + + +Guttman, et al. Standards Track [Page 12] + +RFC 2609 Service Templates and URLs June 1999 + + + The service template is encoded in a UTF-8 character set, but + submitted as a part of an work in progress, which is encoded in ASCII + characters. All characters which are outside of the ASCII range MUST + be escaped using the `\' HEXDIG HEXDIG syntax. For example, the + letter e accent aigue would be represented as "\c3\a9". + Unfortunately, this will detract from the readability of the service + template in the service template submission. Hopefully some public + domain tools will emerge for translating escaped UTF-8 characters + into humanly readable ones. + + Values in value lists are separated by commas. A value list is + terminated by a newline not preceded by a comma. If the newline is + preceded by a comma, the value list is interpreted to continue onto + the next line. + + Attribute identifiers, attribute type names, and flags are all case + insensitive. For ease of presentation, upper and lower case + characters can be used to represent these in the template document. + Newlines are significant in the grammar. They delimit one item from + another, as well as separating parts of items internally. + + String values are considered to be a sequence of non-whitespace + tokens potentially with embedded whitespace, separated from each + other by whitespace. Commas delimit lists of strings. String values + are trimmed so as to reduce any sequence of white space interior to a + string to a single white space. Preceding or trailing white space is + removed. For example: + + " some value , another example " + + is trimmed to + + "some value" and "another example". + + Note that there can be no ambiguity in string tokenization because + values in value lists are separated by a comma. String tokens are + not delimited by double quotes (") as is usually the case with + programming languages. + + Attribute tags and values are useful for directory look-up. In this + case, decoding of character escapes and trimming white space MUST be + performed before string matching. In addition, string matching + SHOULD be case insensitive. + + + + + + + + +Guttman, et al. Standards Track [Page 13] + +RFC 2609 Service Templates and URLs June 1999 + + + Templates obey the following ABNF [8] grammar: + + template = tem-attrs attr-defs + tem-attrs = schemetype schemevers schemetext schemeurl + schemetype = "template-type=" scheme term + schemevers = "template-version=" version-no term + schemetext = "template-description=" newline desc term + schemeurl = "template-url-syntax=" newline url-bnf term + url-bnf = *[ com-chars ] + ; An ABNF describing the <url-path> production + ; in the service: URL grammar of Section 2.1. + scheme = service-type [ "." naming-auth ] + service-type = scheme-name + naming-auth = scheme-name + scheme-name = ALPHA [1*schemechar] [ "." 1*schemechar ] + schemechar = ALPHA / DIGIT / "-" / "+" / + version-no = 1*DIGIT "." 1*DIGIT + langtag = 1*8ALPHA ["-" 1*8ALPHA] + ; See [3] + desc = *[ com-chars ] + ; A block of free-form text for reading by + ; people describing the service in a short, + ; informative manner. + term = newline newline + attr-defs = *( attr-def / keydef ) + attr-def = id "=" attrtail + keydef = id "=" "keyword" newline [help-text] newline + attrtail = type flags newline [value-list] [help-text] + [value-list] newline + id = 1*attrchar + type = "string" / "integer" / "boolean" / "opaque" + flags = ["m"/"M"] ["l"/"L"] ["o"/"O"] ["x"/"X"] + value-list = value newline / value "," value-list / + value "," newline value-list + help-text = 1*( "#" help-line ) + ; A block of free-form text for reading by + ; people describing the attribute and + ; its values. + help-line = *[ com-chars ] newline + attrchar = schemechar / ":" / "_" / "$" / "~" / "@" / "." / + "|" / "<" / ">" / "*" / "&" + value = string / integer / boolean / opaque + string = safe-char *[safe-char / white-sp] safe-char + integer = [ "+" | "-" ] 1*DIGIT + boolean = "true" / "false" + opaque = "\FF" 1*( "\" HEXDIG HEXDIG) + ; Each byte of opaque value is hex encoded. + ; The format corresponds to [10]. + + + +Guttman, et al. Standards Track [Page 14] + +RFC 2609 Service Templates and URLs June 1999 + + + ; Newlines are ignored in decoding opaque + ; values. + com-chars = safe-char / white-sp / "," / ";"/ "%" + safe-char = attrchar / escaped / " " / "!" / '"' / "'" / + "|" / "(" / ")" / "+" / "-" / "." / ":" / + "=" / "?" / "[" / "]" / "{" / "/" / "{" / + "$" + ; All UTF-8 printable characters are + ; included except ",", "%", ";", and "#". + escaped = 1*(`\' HEXDIG HEXDIG) + white-sp = SPACE / HT + newline = CR / ( CR LF ) + +3.2. Semantics of Service Type Templates + + The service type template defines the service attributes and service: + URL syntax for a particular service type. The attribute definition + includes the attribute type, default values, allowed values and other + information. + + Note that the 'template-type', 'template-version', 'template- + description' and 'template-url-syntax' have all been defined as + attributes. These attributes MAY accompany any service registration + using SLPv2. + +3.2.1. Definition of a Service Template + + There are four items included in the service template. The semantics + of each item is summarized below. + + - template-type + + The scheme name of the service scheme. The scheme name consists + of the service type name and an optional naming authority name, + separated from the service type name by a period. See 3.2.2 for + the conventions governing service type names. + + - template-version + + The version number of the service type specification. + + - template-description + + A description of the service suitable for inclusion in text read + by people. + + + + + + +Guttman, et al. Standards Track [Page 15] + +RFC 2609 Service Templates and URLs June 1999 + + + - template-url-syntax + + The syntax of the service type-specific URL part of the service: + URL. + + - attribute definitions + + A collection of zero or more definitions for attributes + associated with the service in service registrations. + + Each of the following subsections deals with one of these items. + +3.2.2. Service Type + + The service scheme consists of the service type name and an optional + naming authority name separated from the service type name by a + period. The service scheme is a string that is appended to the ' + service:' URL scheme identifier, and is the value of the "template- + type" item in the template document. If the naming authority name is + absent it is assumed to be IANA. + +3.2.3. Version Number + + The version number of the service type template is the value of the + "template-version" item. A draft proposal starts at 0.0, and the + minor number increments once per revision. A standardized template + starts at 1.0. Additions of optional attributes add one to the minor + number, and additions of required attributes, changes of definition, + or removal of attributes add one to the major number. The intent is + that an old service template still accurately, if incompletely, + defines the attributes of a service registration if the template only + differs from the registration in its minor version. See Section 4 + for more detail on how to use the template-version attribute. + +3.2.4. Description + + The description is a block of text readable by people in the language + of the template and is the value of the "template-description" item. + It should be sufficient to identify the service to human readers and + provide a short, informative description of what the service does. + + If the service type corresponds to a particular protocol, the + protocol specification must be cited here. The protocol need not be + a standardized protocol. The template might refer to a proprietary + specification, and refer the reader of the template to a contact + person for further information. + + + + + +Guttman, et al. Standards Track [Page 16] + +RFC 2609 Service Templates and URLs June 1999 + + +3.2.5. Syntax of the Service Type-specific URL Part + + The syntax of the service type-specific part of the service: URL is + provided in the template document as the value of the "template-url- + syntax" item. The <url-path> field of the service: URL is designed + to provide additional information to locate a service when the + <addr-spec> field is not sufficient. The <url-path> field + distinguishes URLs of a particular service type from those of another + service type. For instance, in the case of the lpr service type, the + <url-path> may be defined so that it must include the queue name, but + other service types may not require this information. + + 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. The syntax is included in the + template document as an ABNF [8] following the rules for URL syntax + described in [5]. There is no requirement for a service scheme to + support a <url-path>. The <url-path> field can be very simple, or + even omitted. If the URL scheme has already been standardized, the + "template-url-syntax" item SHOULD include a reference to the + appropriate standardization documents. Abstract service types may + defer this field to the template documents describing their concrete + instances. + +3.2.6. Attribute Definition + + The bulk of the template is typically devoted to defining service + type-specific attributes. An attribute definition precisely + specifies the attribute's type, other restrictions on the attribute + (whether it is multi-valued, optional, etc), some text readable by + people describing the attribute, and lists of default and allowed + values. The only required information is the attribute's type, the + rest are optional. Registration, deregistration and the use of + attributes in queries can be accomplished using the Service Location + Protocol [10] or other means, and discussion of this is beyond the + scope of the document. + + Attributes are used to convey information about a given service for + purposes of differentiating different services of the same type. + They convey information to be used in the selection of a particular + service to establish communicate with, either through a program + offering a human interface or programmatically. Attributes can be + encoded in different character sets and in different languages. The + procedure for doing this is described in Section 6. + + An attribute definition begins with the specification of the + attribute's identifier and ends with a single empty line. Attributes + definitions have five components (in order of appearance in a + + + +Guttman, et al. Standards Track [Page 17] + +RFC 2609 Service Templates and URLs June 1999 + + + definition): + + 1. An attribute identifier which acts as the name of the attribute, + + 2. Attribute descriptors (type and flags), + + 3. An optional list of values which are assigned to the attribute by + default, + + 4. An optional block of text readable by people providing a short, + informative description of the attribute, + + 5. An optional list of allowed values which restrict the value or + values the attribute can take on. + +3.2.6.1. The Attribute Identifier + + An attribute definition starts with the specification of the + attribute's identifier. The attribute's identifier functions as the + name of the attribute. Note that the characters used to compose an + attribute identifier are restricted to those characters considered + unrestricted for inclusion in a URL according to [5]. The reason is + that services can display prominent attributes in their service: URL + registrations. Each attribute identifier must be unique in the + template. Since identifiers are case folded, upper case and lower + case characters are the same. + +3.2.6.2. The Attribute Type + + Attributes can have one of five different types: string, integer, + boolean, opaque, or keyword. The attribute's type specification is + separated from the attribute's identifier by an equal sign ("=") and + follows the equal sign on the same line. The string, signed integer, + and boolean types have the standard programming language or database + semantics. Integers are restricted to those signed values that can + be represented in 32 bits. The character set used to represent + strings is not specified at the time the template is defined, but + rather is determined by the service registration. Booleans have the + standard syntax. Opaques are byte escaped values that can be used to + represent any other kind of data. Keywords are attributes that have + no characteristics other than their existence (and possibly the + descriptive text in their definition). + + Keyword and boolean attributes impose restrictions on the following + parts of the attribute definition. Keyword attribute definitions + MUST have no flag information following the type definition, nor any + default or allowed values list. Boolean attributes are single value + only, i.e., multi-valued boolean attributes are not allowed. + + + +Guttman, et al. Standards Track [Page 18] + +RFC 2609 Service Templates and URLs June 1999 + + +3.2.6.3. Attribute Flags + + Flags determine other characteristics of an attribute. With the + exception of keyword attributes, which may not have any flags, flags + follow the attribute type on the same line as the attribute + identifier, and are separated from each other by whitespace. Flags + may appear in any order after the attribute type. Other information + must not follow the flags, and only one flag identifier of a + particular flag type is allowed per attribute definition. + + The semantics of the flags are as follows: + + - o or O + + Indicates that the attribute is optional. If this flag is + missing, the attribute is required in every service registration. + + - m or M + + Indicates that the attribute can take on multiple values. If + this flag is present, every value in a multi-valued attribute + has the same type as the type specified in the type part of the + attribute definition. Boolean attributes must not include this + flag. + + - l or L + + Indicates that attribute is literal, i.e. is not meant to be + translated into other languages. If this flag is present, the + attribute is not considered to be readable by people and should + not be translated when the template is translated. See Section 6 + for more information about translation. + + - x or X + + Indicates that clients SHOULD include the indicated attribute + in requests for services. Neglecting to include this attribute + will not sufficiently differentiate the service. If services are + obtained without selecting this attribute they will quite likely + be useless to the client. + + The values for multivalued attributes are an unordered set. + Deletions of individual values from a multivalued attribute are not + supported, and deletion of the attribute causes the entire set of + values to be removed. + + + + + + +Guttman, et al. Standards Track [Page 19] + +RFC 2609 Service Templates and URLs June 1999 + + +3.2.6.4. Default Value or List + + If the attribute definition includes a default value or, in the case + of multivalued attributes, a default values list, it begins on the + second line of the attribute definition and continues over the + following lines until a line ends without a comma. As a consequence, + newlines cannot be embedded in values unless escaped. See Section + 2.1. + + Particular attribute types and definitions restrict the default + values list. Keyword attributes must not have a list of defaults. + If an optional attribute's definition has an allowed values list, + then a default value or list is not optional but required. The + motivation for this is that defining an attribute with an allowed + values list is meant to restrict the values the attribute can take + on, and requiring a default value or list assures that the default + value is a member of the given set of allowed values. + + The default value or list indicates what values the attribute is + given if no values are assigned to the attribute when a service is + registered. If an optional attribute's definition includes no + default value or list, the following defaults are assigned: + + 1. String values are assigned the empty string, + + 2. Integer values are assigned zero, + + 3. Boolean values are assigned false, + + 4. Opaque values are assigned a byte array containing no values, + + 5. Multi-valued attributes are initialized with a single value. + + For purposes of translating nonliteral attributes, the default values + list is taken to be an ordered set, and translations MUST maintain + that order. + +3.2.6.5. Descriptive Text + + Immediately after the default values list, if any, a block of + descriptive text SHOULD be included in the attribute definition. + This text is meant to be readable by people, and should include a + short, informative description of the attribute. It may also provide + additional information, such as a description of the allowed values. + This text is primarily designed for display by interactive browsing + tools. The descriptive text is set off from the surrounding + definition by a crosshatch character ("#") at the beginning of the + line. The text should not, however, be treated as a comment by + + + +Guttman, et al. Standards Track [Page 20] + +RFC 2609 Service Templates and URLs June 1999 + + + parsing and other tools, since it is an integral part of the + attribute definition. Within the block of descriptive text, the text + is transferred verbatim, including indentation and line breaks, so + any formatting is preserved. + +3.2.6.6. Allowed Values List + + Finally, the attribute definition concludes with an optional allowed + values list. The allowed values list, if any, follows the + descriptive text, or, if the descriptive text is absent, the initial + values list. The syntax of the allowed values list is identical to + that of the initial values list. The allowed values list is also + terminated by a line that does not end in a comma. If the allowed + values list is present, assignment to attributes is restricted to + members of the list. + + As with the default values list, the allowed values list is also + considered to be an ordered set for purposes of translation. + +3.2.6.7. Conclusion of An Attribute Definition + + An attribute definition concludes with a single empty line. + +4. A Process For Standardizing New Service Types + + New service types can be suggested simply by providing a service type + template and a short description about how to use the service. The + template MUST have its "template-version" template attribute set to + 0.0. + + MAJOR revision numbers come before the '.', MINOR revision numbers + come after the '.'. + + The minor version number increments once with each change until it + achieves 1.0. There is no guarantee any version of the service + template is backward compatible before it reaches 1.0. + + Once a service template has reached 1.0, the definition is "frozen" + for that version. New templates must be defined, of course, to + refine that definition, but the following rules must be followed: + + A MINOR revision number signifies the introduction of a compatible + change. A MAJOR revision number signifies the introduction of an + incompatible change. This is formalized by the following rules: + + - Any new optional attribute defined for the template increases + the minor version number by one. All other attributes for the + version must continue to be supported as before. A client which + + + +Guttman, et al. Standards Track [Page 21] + +RFC 2609 Service Templates and URLs June 1999 + + + supports 1.x can still use later versions of 1.y (where x<y) as + it ignores attributes it doesn't know about. + + - Adding a required attribute, removing support for an attribute + or changing definition of an attribute requires changing the + major version number of a service template. A client application + may be unable to make use of this information, or it may need + to obtain the most recent service template to help the user + interpret the service information. + + The template is submitted to a special mailing list, see section 5. + This document must include a 'template begins here' and 'template + ends here' marking, in text, so that it is trivial to cut and paste + the template from the submission. + + The list will be available at svrloc-list@iana.org. Ideally, experts + in the implementation and deployment of the particular protocol are + consulted so as to add or delete attributes or change their + definition to make the template as useful as possible. The mailing + list will be maintained even when the SVRLOC WG goes dormant for the + purpose of discussing service templates. + + All published versions of the template must be available on-line, + including obsolete ones. + + Once consensus is achieved, the template should be reissued with + possible corrections, having its Version number set to 1.0. + Templates with version numbers below 1.0 are not submitted to the + IANA. From that point onwards, templates are submitted. See Section + 5 for details on how templates are submitted to an IANA registry of + templates. + +5. IANA Considerations + + It is the responsibility of the IESG (e.g., Applications Area + director) to appoint a Designated Expert (see [12].) Anyone may ask + for clarification of a service template. This is to solicit input + from the concerned community. It is up to the appointed reviewer to + determine whether clarification requests are satisfied. It is the + reviewer's responsibility to see that all reasonable clarification + requests are met before the template is submitted for inclusion in + the IANA registry. + + When the reviewer has determined that the template submission is + ready, he or she will submit the template to the IANA for inclusion + in a registry. Mailing list participants supply input to the process + but do not make the decision whether to accept a service template. + + + + +Guttman, et al. Standards Track [Page 22] + +RFC 2609 Service Templates and URLs June 1999 + + + If a dispute arises over the decisions made by the reviewer, the + matter may be appealed according to normal IETF procedure as + described for the Standards Track process. + + The IANA will maintain a mail forwarding alias for the work of this + list, so that "svrloc-list@iana.org" points to a mail server supplied + by a volunteer organization. + + The service template submission MUST be of the form: + + Name of submitter: + Language of service template: + Security Considerations: + Template Text: + ----------------------template begins here----------------------- + . . . + -----------------------template ends here------------------------ + + The service template file has a naming convention: + + <service-type> "." <version-no> "." <langtag> + + Each of these fields are defined in Section 2. They correspond to + the values of the template fields "type", "template-version". The + files for the example templates in this document (see Section A) are + called: + + "foo.0.0.en", + "Net-Transducer.0.0.en", + "Net-Transducer:Thermometer.0.0.de" and + "Net-Transducer:Thermomoter.0.0.en". + + The reviewer will ensure that the template submission to IANA has the + correct form and required fields. + + No service type template will be accepted for inclusion in the + service template registry unless the submission includes a security + considerations section and contact information for the template + document author. + + The IANA will maintain a registry containing both the service type + templates, and the template description document containing the + service type template, including all previous versions. The IANA + will receive notice to include a service template in the registry + by email from the reviewer. This message will include the service + template itself, which is to be registered. + + + + + +Guttman, et al. Standards Track [Page 23] + +RFC 2609 Service Templates and URLs June 1999 + + + Neither the reviewer nor the IANA will take any position on claims of + copyright or trademark issues with regard to templates. + +6. Internationalization Considerations + + The service: URL must be encoded using the rules set forth in [5]. + The character set encoding is limited to specific ranges within the + US-ASCII character set [4]. + + The template is encoded in UTF-8 characters. + +6.1. Language Identification and Translation + + The language used in attribute strings should be identified supplying + a Language Tag [3] in the Service Template submission (see Section + 5). + + A program can translate a service registration from one language to + another provided it has both the template of the language for the + registration and the template of the desired target language. All + standardized attributes are in the same order in both templates. All + non-arbitrary strings, including the descriptive help text, is + directly translatable from one language to another. Non-literal + attribute definitions, attribute identifiers, attribute type names, + attribute flags, and the boolean constants "true" and "false" are + never translated. Translation of attribute identifiers is prohibited + because, as with domain names, they can potentially be part of a + service: URL and therefore their character set is restricted. In + addition, as with variable identifiers in programming languages, they + could become embedded into program code. + + All strings used in attribute values are assumed translatable unless + explicitly defined as being literal, so that best effort translation + (see below) does not modify strings which are meant to be interpreted + by a program, not a person. + + An example of a translated service template is included in Section A. + + There are two ways to go about translation: standardization and best + effort. + + When the service type is standardized, more than one document can be + submitted for review. One service type description is approved as a + master, so that when a service type template is updated in one + language, all the translations (at least eventually) reflect the same + semantics. + + + + + +Guttman, et al. Standards Track [Page 24] + +RFC 2609 Service Templates and URLs June 1999 + + + If no document exists describing the standard translation of the + service type, a 'best effort' translation for strings should be done. + +7. Security Considerations + + Service type templates provide information that is used to interpret + information obtained by the Service Location Protocol. If these + templates are modified or false templates are distributed, services + may not correctly register themselves, or clients might not be able + to interpret service information. + + The service: URLs themselves specify the service access point and + protocol for a particular service type. These service: URLs could be + distributed and indicate the location of a service other than that + normally want to used. The Service Location Protocol [10] + distributes service: URLs and has an authentication mechanism that + allows service: URLs of registered services to be signed and for the + signatures to be verified by clients. + + Each Service Template will include a security considerations section + which will describe security issues with using the service scheme for + the specific Service Type. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Guttman, et al. Standards Track [Page 25] + +RFC 2609 Service Templates and URLs June 1999 + + +A. Service Template Examples + + The text in the template example sections is to be taken as being a + single file. They are completely fictitious (ie. the examples do + not represent real services). + + The FOO example shows how to use service templates for an application + that has very few attributes. Clients request the FOO server where + their user data is located by including their user name as the value + of the user attribute. + + The Net-Transducer example shows how abstract service types are + defined and how a corresponding concrete instance is defined. A + system might support any of several NetTransducer services. Here we + give only one concrete instance of the abstract type. + + It is not necessary to register concrete templates for an abstract + service type if the abstract service type template is completely + clear as to what possible values can be used as a concrete type, and + what their interpretation is. + +A.1. FOO + + The FOO service template submission example follows: + + Name of submitter: "Erik Guttman" <Erik.Guttman@sun.com> + Language of service template: en + Security Considerations: + If the USER and GROUPS attributes are included a + possibility exists that the list of identities for users or groups + can be discovered. This information would otherwise be difficult + to discover. + + Template Text: + -------------------------template begins here----------------------- + template-type=FOO + + template-version=0.0 + + template-description= + The FOO service URL provides the location of an FOO service. + + template-url-syntax= + url-path= ; There is no URL path defined for a FOO URL. + + users= string M L O + # The list of all users which the FOO server supports. + + + + +Guttman, et al. Standards Track [Page 26] + +RFC 2609 Service Templates and URLs June 1999 + + + groups= string M L O + # The list of all groups which the FOO server supports. + --------------------------template ends here------------------------ + + This template could be internationalized by registering another + version, say in German: + + Name of submitter: "Erik Guttman" <Erik.Guttman@sun.com> + Language of service template: de + Security Considerations: + Wenn die USER und GROUPS Eigenschaften inbegriffen sind, + besteht die Moeglichkeit, dass die Liste der Identitaeten + von Benutzern oder Gruppen endeckt werden kann. Diese + Information wurde unter anderen Umstaenden schwierig zu + entdecken sein. + + Template Text: + -------------------------template begins here----------------------- + template-type=FOO + + template-version=0.0 + + template-description= + Der FOO Service URL zeigt die Stelle von einem Foo Service an. + + template-url-syntax= + url-path= ; Es gibt keinen fuer den FOO URL definierten Pfad. + + users= string M L O + # Die Liste aller Users, die der FOO Server unterstuetzt. + + groups= string M L O + # Die Liste aller Gruppen, die der FOO Server unterstuetzt. + --------------------------template ends here------------------------ + + Note that the attribute tags are not translated. If translations + are desired, the suggested convention for doing so is to define a + separate attribute called localize-<tag> for each attribute tag which + is to be localized. This will aid in displaying the attribute tags + in a human interface. + + For example, in this case above, the following two attributes could + be defined: + + localize-users= string + Benutzer + + localize-groups= string + + + +Guttman, et al. Standards Track [Page 27] + +RFC 2609 Service Templates and URLs June 1999 + + + Gruppen + + The attributes (in SLPv2 attribute list format) for a service + registration of a FOO service based on this template, in German, + could be: + + (users=Hans,Fritz),(groups=Verwaltung,Finanzbuchhaltung), + (template-type=FOO),(template-version=0.0),(template-description= + Der FOO Service URL zeigt die Stelle von einem Foo Service an.), + (template-url-syntax= \OD url-path= ; Es gibt kein fuer den FOO + URL definiert Pfad. \OD),(localize-users=Benutzer), + (localize-groups=Gruppen) + + Anyone obtaining these attributes could display "Benutzer=Hans,Fritz" + in a human interface using the included information. Note that the + template attributes have been included in this registration. This is + OPTIONAL, but makes it possible to discover which template was used + to register the service. + +A.2. Abstract Service Type: Net-Transducer + + An example submission of an abstract service type template is: + + Name of submitter: "Erik Guttman" <Erik.Guttman@sun.com> + Language of service template: en + Security Considerations: + See the security considerations of the concrete service types. + + Template Text: + -------------------------template begins here----------------------- + template-type=Net-Transducer + + template-version=0.0 + + template-description= + This is an abstract service type. The purpose of the Net- + Transducer service type is to organize into a single category + all network enabled Transducers which have certain properties. + + template-url-syntax= + url-path= ; Depends on the concrete service type. + ; See these templates. + + sample-units= string L + # The units of sample that the Transducer provides, for instance + # C (degrees Celsius), V (Volts), kg (Kilograms), etc. + + sample-resolution= string L + + + +Guttman, et al. Standards Track [Page 28] + +RFC 2609 Service Templates and URLs June 1999 + + + # The resolution of the Transducer. For instance, 10^-3 means + # that the Transducer has resolution to 0.001 unit. + + sample-rate= integer L + # The speed at which samples are obtained per second. For + # instance 1000 means that one sample is obtained every millisecond. + + --------------------------template ends here------------------------ + +A.3. Concrete Service Type: Net-Transducer:Thermometer + + This is another service template submission example, supplying a + concrete service type corresponding to the abstract template above. + + Name of submitter: "Erik Guttman" <Erik.Guttman@sun.com> + Language of service template: en + Security Considerations: + There is no authentication of the Transducer output. Thus, + the Thermometer output could easily be spoofed. + + Template Text: + -------------------------template begins here----------------------- + template-type=service:Net-Transducer:Thermometer + + template-version=0.0 + + template-description= + The Thermometer is a Net-Transducer capable of reading temperature. + The data is read by opening a TCP connection to one of the ports + in the service URL and reading an ASCII string until an NULL + character is encountered. The client may continue reading data at + no faster than the sample-rate, or close the connection. + + template-url-syntax= + url-path = "ports=" ports-list + port-list = port / port "," ports + port = 1*DIGIT + ; See the Service URL <port> production rule. + ; These are the ports connections can be made on. + + location-description=string + # The location where the Thermometer is located. + + operator=string O + # The operator to contact to have the Thermometer serviced. + + --------------------------template ends here------------------------ + + + + +Guttman, et al. Standards Track [Page 29] + +RFC 2609 Service Templates and URLs June 1999 + + +A.4. service: URLs and SLP + + A user with an FOO enabled calendar application should not be + bothered with knowing the address of their FOO server. The calendar + client program can use SLP to obtain the FOO service: URL + automatically, say 'service:foo://server1.nosuch.org', by issuing a + Service Request. In the event that this FOO server failed, the + Calendar client can issue the same service request again to find the + backup FOO server, say 'service:foo://server2.nosuch.org'. In both + cases, the service: URL conforms to the FOO service template as do + the associated attributes (user and group.) + + A network thermometer based on the above template could be advertised + with the SLPv2 attribute list: + + URL = service:net-transducer:thermometer://v33.test/ports=3211 + Attributes = (location-description=Missile bay 32), + (operator=Joe Agent), (sample-units=C), + (sample-resolution=10^-1),(sample-rate=10), + (template-type=service:net-transducer:thermometer), + (template-version=0.0),(template-description= + The Thermometer is a Net-Transducer capable of reading temperature. + The data is read by opening a TCP connection to one of the ports + in the service URL and reading an ASCII string until an NULL + character is encountered. The client may continue reading data at + no faster than the sample-rate, or close the connection.), + (template-url-syntax= \0D "ports=" port-list \OD + port-list = port / port "," ports \OD + port = 1*DIGIT \OD + ; See the Service URL <port> production rule. \OD + ; These are the ports connections can be made on.\OD) + + This might be very useful for a technician who wanted to find a + Thermometers in Missile bay 32, for example. + + Note that the template attributes are advertised. The + template-url-syntax value requires explicit escaped CR characters so + that the ABNF syntax is correct. + +B. Acknowledgments + + Thanks to Michael Day and Leland Wallace for assisting with the IPX + and AppleTalk address syntax portions. Ryan Moats provided valuable + feedback throughout the writing of this document. + + + + + + + +Guttman, et al. Standards Track [Page 30] + +RFC 2609 Service Templates and URLs June 1999 + + +C. References + + [1] Protocol and service names, October 1994. + ftp://ftp.isi.edu/in-notes/iana/assignments/service-names. + + [2] Port numbers, July 1997. + ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers. + + [3] Alvestrand, H., "Tags for the Identification of Languages", + RFC 1766, March 1995. + + [4] ANSI. Coded Character Set -- 7-bit American Standard code for + Information Interchange. X3.4-1986, 1986. + + [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, + August 1998. + + [6] Bradner, S., "Key Words for Use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [7] Apple Computer. Inside Macintosh. Addison-Wesley, 1993. + + [8] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [9] S. Gursharan, R. Andrews, and A. Oppenheimer. Inside AppleTalk. + Addison-Wesley, 1990. + + [10] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service + Location Protocol Version 2", RFC 2608, June 1999. + + [11] Myers, J., "Simple Authentication and Security Layer (SASL)", + RFC 2222, October 1997. + + [12] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs, BCP 26, RFC 2434, + October 1998 + + [13] Newman C. and J. Myers, "ACAP -- Application Configuration + Access Protocol", RFC 2244, November 1997. + + [14] Inc Novell. IPX RIP and SAP Router Specification. Part Number + 107-000029-001, Version 1.30, May 1996. + + [15] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service + Location Protocol", RFC 2165, July 1997. + + + + +Guttman, et al. Standards Track [Page 31] + +RFC 2609 Service Templates and URLs June 1999 + + + [16] Yergeau, F., "UTF-8, a transformation format of ISO 10646", + RFC 2279, January 1998. + +D. Authors' Addresses + + Questions about this memo can be directed to: + + Erik Guttman + Sun Microsystems + Bahnstr. 2 + 74915 Waibstadt + Germany + + Phone: +49 7263 911484 + Fax: +1 650 786 5992 + EMail: erik.guttman@sun.com + + + Charles E. Perkins + Sun Microsystems + 15 Network Circle + Menlo Park, CA 94303 + USA + + Phone: +1 650 786 6464 + Fas: +1 650 786 6445 + EMail: cperkins@sun.com + + + James Kempf + Sun Microsystems + 15 Network Circle + Menlo Park, CA 94303 + USA + + Phone: +1 650 786 5890 + Fax: +1 650 786 6445 + EMail: james.kempf@sun.com + + + + + + + + + + + + + +Guttman, et al. Standards Track [Page 32] + +RFC 2609 Service Templates and URLs June 1999 + + +E. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Guttman, et al. Standards Track [Page 33] + |