The following section supplies formal definitions for fields and protocol elements introduced in the sections indicated.
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 AttrRqst
20.1. Previous Responders’ Address Specification
The previous responders’ Address Specification is specified as <Previous Responders’ Address Specification> ::=
<addr-spec> |
<addr-spec>, <Previous Responders’ Address Specification>
i.e., a list separated by commas with no intervening white space.
The Address Specification is the address of the Directory Agent or Service Agent which supplied the previous response. The format for Address Specifications in Service Location is defined in section 20.4. The comma delimiter is required between each <addr-spec>. The use of dotted decimal IP address notation should only be used in environments which have no Domain Name Service.
Example:
RESOLVO.NEATO.ORG,128.127.203.63
20.2. Formal Definition of the "service:" Scheme
A URL with a "service:" scheme is used in the SrvReg, SrvDereg, SrvRply and AttrRqst messages in Service Location. URLs are defined in RFC 1738 [6]. A URL with the "service:" scheme must contain at least:
<url> ::= service:<srvtype>://<addr-spec>
where:
service the URL scheme for Service Location, to return Replies.
<srvtype> a string; Service Types may be standardized by developing 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 is 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 this is not the case, the Service Type MUST be defined in such a way that attribute information will include all necessary
configuration and protocol information. A User Agent MUST therefore be able to use either a "service:" URL alone or a "service:" URL in conjunction with service attributes to make use of a service.
20.2.1. Service Type String
The Service Type is a string describing 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) the ’suffix’ is considered to be the Naming Authority of the service. If the Naming Authority is omitted, IANA is assumed to be the Naming Authority.
Service Types developed for in-house or experimental use may have any name and attribute semantics provided that they do not conflict with the standardized Service Types.
20.3. Attribute Information
The <attr-list> is returned in the Attribute Reply if the Attribute Request does not result in an empty result.
<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 prior to 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>, as the comma is used as 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 is:
<addr-spec> ::= [<user>:<password>@]<host>[:<port>]
<host> ::= Fully qualified domain name | dotted decimal IP address notation
When no Domain Name Server is available, SAs and DAs must use dotted decimal conventions for IP addresses. Otherwise, it is preferable to use a fully qualified domain name wherever possible as renumbering of host addresses will make IP addresses invalid over time.
Generally, just the host domain name (or address) is returned. When there is a non-standard port for the protocol, that should be
returned as well. Some applications may make use of the
<user>:<password>@ syntax, but its use is not 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 purposes of lexical comparison.
Attribute values are strings containing any characters with the exception of ’(’, ’)’, ’=’, ’>’, ’<’, ’/’, ’*’, and ’,’ (the comma) except in the case described below where opaque values are encoded.
These characters may be included using the character value escape mechanism described in section 17.1.1.
While an attribute can take any value, there are three types of values which differentiate themselves from general strings:
Booleans, Integers and Opaque values.
- Boolean values are either "TRUE" or "FALSE". This is the case regardless of the language (i.e. in French or Telugu, Boolean TRUE is "TRUE", as well 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 such except integers. 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 which 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