idnits 2.17.1 draft-ietf-svrloc-service-scheme-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 191: '... Each service scheme MUST obey the URL conventions defined in [4]....' RFC 2119 keyword, line 334: '...lient, the agent SHOULD also keep trac...' RFC 2119 keyword, line 435: '...h attributes are REQUIRED with every s...' RFC 2119 keyword, line 436: '... service type, and which are OPTIONAL....' RFC 2119 keyword, line 457: '... for standardization MUST be encoded in ASCII [2] and be in English....' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 971 has weird spacing: '...sun.com cpe...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1766 (ref. '1') (Obsoleted by RFC 3066, RFC 3282) -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-09) exists of draft-fielding-url-syntax-05 -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 1738 (ref. '4') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1521 (ref. '5') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) == Outdated reference: A later version (-04) exists of draft-ietf-drums-abnf-02 ** Obsolete normative reference: RFC 2052 (ref. '7') (Obsoleted by RFC 2782) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- No information found for draft-ietf-svrloc-advertise - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' -- Unexpected draft version: The latest known version of draft-ietf-svrloc-protocol is -16, but you're referring to -17. (However, the state information for draft-ietf-svrloc-advertise is not up-to-date. The last update was unsuccessful) Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Service Location Working Group Erik Guttman 2 INTERNET DRAFT Charles Perkins 3 6 June 1997 Sun Microsystems 5 Service Templates and service: Schemes 6 draft-ietf-svrloc-service-scheme-01.txt 8 Status of This Memo 10 This document is a submission by the Service Location Working Group 11 of the Internet Engineering Task Force (IETF). Comments should be 12 submitted to the srvloc@corp.home.net mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at 23 any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check 27 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 28 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North 29 Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), 30 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 32 Abstract 34 Service: schemes define URLs (called "service: URLs" in this 35 document) which are primarily intended to be used by the Service 36 Location Protocol in order to distribute service access information. 37 These schemes provide an extensible framework for client based 38 network software to obtain configuration information required to make 39 use of network services. When registering a service: URL with a 40 Directory Agent, the URL may be accompanied by a set of well defined 41 attributes which define the charateristics of the service. These 42 attributes may convey configuration information to client software, 43 or service characteristics meaningful to end users. 45 This document describes how to define and standardize new service 46 types and attributes for use with the service: scheme using Service 47 Templates. These templates are human and machine readable. They 48 may be used by administrative tools to parse service registration 49 information and by client applications to provide localized 50 translations of service attribute strings. 52 Contents 54 Status of This Memo i 56 Abstract i 58 1. Introduction 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Service Schemes . . . . . . . . . . . . . . . . . . . . . 4 61 1.3. Related work . . . . . . . . . . . . . . . . . . . . . . 5 62 1.4. Changes made since the last version . . . . . . . . . . . 5 63 1.5. Open issues and work to be done . . . . . . . . . . . . . 6 65 2. Use of service: URLs 6 67 3. Specifying A New Service Type 7 68 3.1. Service Type Specifications . . . . . . . . . . . . . . . 7 69 3.1.1. Service Type . . . . . . . . . . . . . . . . . . 7 70 3.1.2. The service: 'url-path' information . . . . . . 8 71 3.1.3. Attributes . . . . . . . . . . . . . . . . . . . 8 72 3.2. Specifying Attributes . . . . . . . . . . . . . . . . . . 8 73 3.2.1. Service Templates and attributes . . . . . . . . 9 74 3.2.2. Service Templates String Encoding . . . . . . . . 9 75 3.2.3. Attributes with multiple values . . . . . . . . . 12 76 3.2.4. Grouping attribute values together in records . . 12 77 3.3. Special attributes . . . . . . . . . . . . . . . . . . . 13 78 3.3.1. Service Type Language . . . . . . . . . . . . . . 13 79 3.3.2. Version . . . . . . . . . . . . . . . . . . . . . 13 80 3.3.3. url-path rules . . . . . . . . . . . . . . . . . 14 82 4. A Process For Standardizing New Service Types 14 84 5. Encoding Rules for Service Type URLs 15 86 6. Examples 16 87 6.1. SLP Directory Agent . . . . . . . . . . . . . . . . . . . 16 88 6.2. POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 7. General Service Template 17 91 7.1. Obtaining Service Templates dynamically . . . . . . . . . 18 93 8. Internationalization Considerations 18 94 8.1. Character Set identification and use . . . . . . . . . . 18 95 8.2. Language identification and translation . . . . . . . . . 19 97 9. Security Considerations 19 99 1. Introduction 101 This document describes a class of schemes which will allow network 102 services to define their service access information, using a standard 103 notation. 105 In addition it describes how to define a set of attributes to 106 associate with a service: URL. These attributes will allow end users 107 and programs to select between network services of the same type that 108 have different capabilities. 110 A client may use these attributes to select a particular service 111 (obtain the service: URL) that has the configuration it needs. The 112 minimal encoding rules for attributes are specified. 114 Service Type templates are used to describe in a standard way those 115 services which use the service: URL. The rules for specifying a 116 scheme are provided, along with two examples. Templates are used the 117 following distinct purposes: 119 1. Standardization 121 The template is reviewed before it is standardized. Once it is 122 standardized, all versions of the template are archived by IANA. 124 2. Service Registration 126 Servers making use of the Service Location Protocol will register 127 themselves and their attributes. They will use the templates to 128 generate the service registrations; the service must pick from 129 among the allowable values. 131 3. Client presentation of Service Information 133 Client applications may display service information. The 134 template provides type information and explanatory text which may 135 be helpful in producing user interfaces. 137 4. Internationalization 139 If a client application has the template for a given service type 140 in two different languages, the attributes may be translated back 141 and forth between the two languages. 143 A Service may use templates to register services in more than 144 one language, though it has been configured by the system 145 administrator to register in a single language. 147 QUESTION: Which of several homonyms would be the one known 148 to user agents processing the translated information? 150 All grammar encoding follows the Augmented BNF (ABNF) [6] for syntax 151 specifications with a few deviations. 153 QUESTION: What are the deviations? 155 1.1. Terminology 157 In order to reduce confusion, some terminology is introduced. 159 service: URL 161 A URL, registered by a service agent of a particular service 162 type, that conforms to any "service scheme" definition. 164 service type 166 A type of service all of whose agents are accessed by service: 167 URLs of the same scheme (a service scheme, below). The name 168 of the type of service is the part of the service scheme name 169 which follows the initial string "service:". 171 service scheme 173 A scheme, whose name start with the string "service:" and is 174 followed by the service type name, constructed according to the 175 rules in this document. 177 service template 179 A formal description of the service attributes and service 180 scheme associated with a particular service type. a particular 181 service may be selected by obtaining the service: URL 182 registered by that service. 184 general service template 186 A template for describing service templates -- for instance as 187 is contained within this document. 189 1.2. Service Schemes 191 Each service scheme MUST obey the URL conventions defined in [4]. 193 The scheme specific information following the service: scheme 194 provides the service type and address of a network service. It may 195 additionally include service type specific information. The form of 196 a service: URL is as follows: 198 "service:" service-type ":" service-part 200 where the service-part typically has the following form: 202 /addr-family/addr-spec/url-path;FAQ 204 and the last field is never required to exist in any service 205 location registration, but is sometimes provided for convenience of 206 interactive user agents. The formal syntax for a service: URL is 207 given in Section 5. 209 The service-type string indicates the type of service. The service 210 type determines the semantics of the service-part and of the 211 attributes associated with the service: URL. The is 212 IP by default (if not present), but can be used to indicate the use 213 other address families such as IPX and Appletalk. In this document, 214 the addr-family> is always IP, so that the field can be omitted; all 215 service-parts will start with "//". Next, the service-part includes 216 a address specification (an ), which is typically either 217 a domain name (DNS) or an IP address for the service, and possibly a 218 port number. The service-part allows more information to be provided 219 (by way of ) that can uniquely locate the service or 220 resource if the is not sufficient for that purpose. 222 The FAQ is actually composed of a list of "attribute = value" 223 elements, describing for the user the attributes that are associated 224 with the service: URL. This might be done in situations where the 225 service: URL is used in a context where it was not automatically 226 selected by picking desired attributes. When a human obtains a 227 URL and needs to ask questions about how to use it, hopefully the 228 attribute values provided in the FAQ can help. For instance, if 229 the keyword "PostScript" were provided in a service:printer URL, a 230 user would be able to guess that the printer could correctly print 231 PostScript documents. 233 Other than in a FAQ, attributes associated with the service: URL are 234 not typically included in the URL. They are stored and retrieved 235 using other mechanisms. The service: URL is uniquely identified 236 with a particular service agent, and is used when registering 237 or requesting the attribute information. The Service Location 238 Protocol [10] specifies how such information may be advertised 239 by network services and obtained by client software. Service 240 agents would not typically advertise URLs with FAQs unless manually 241 configured to do so by a system administrator, and a user agent that 242 obtains a service: URLs by issuing a Service Request will already 243 have all the necessary attribute information to make use of the 244 service: URL. 246 Attributes are associated with service: URLs for three reasons: 248 1. Many servers have optional features. Clients which require or 249 prefer to make use of these features can proceed to do so without 250 protocol negotiation or feature selection. Attributes serve as 251 a mechanism for servers to distribute information about their 252 configuration, capabilities and characteristics (even dynamic 253 qualities, such as status or load.) 255 2. Client software may have particular requirements. The attributes 256 associated with a given URL allow for automatic selection of 257 services which have certain features. For example, client 258 software may require a server which has a particular version of 259 something, or which has access to specific resources. 261 3. Attributes support selection of service instances by 262 characteristic as opposed to simply by type. These attributes 263 may be used to give users information enabling the selection of 264 particular services when browsing service directories or the 265 available services on the local network. 267 1.3. Related work 269 The "Finding Stuff" work by Ryan Moats and Martin Hamilton uses 270 service: URLs provide access information about arbitrary network 271 protocols through DNS [9]. They do not associate service attributes 272 with these URLs. The URLs may contain nonstandard service port 273 information for services advertised in the DNS. DNS SRV Resource 274 Records are a mechanism which provides a way to obtain a service by 275 type for a given domain [7], without being able to specify which of 276 the (possibly numerous) instances of the service type would satisfy 277 the needs of the user agent. 279 1.4. Changes made since the last version 281 Removed: 283 - The long template examples. 285 - Description of the Service Specific Multicast Addresses (which 286 are no longer needed in the Service Templates.) 288 - 'Record based' attribute values. 290 - The possibility for putting CR, LF, or TAB in most places. 292 Added: 294 - Terminology 296 - Further explanation of Service Templates. 298 - New syntax for Service Templates. 300 - A proposal on how to use Templates for internationalization. 302 - Some security considerations. 304 1.5. Open issues and work to be done 306 - Justification will be added (as done in the URL process 307 draft [3]). 309 - Encoding rules for transforming a Service Template to an LDAP 310 Schema will be added. 312 - The process for standardizing a new service type needes to be 313 sharpened. In particular, feedback from the Applications Area 314 Directors needs to be solicited. 316 - Description of how Service Templates themselves may be registered 317 and obtained in a network is needed. Why isn't SLP enough for 318 this purpose? 320 2. Use of service: URLs 322 The service: URL is intended to allow arbitrary client/server and 323 peer to peer systems to make use of a standardized dynamic service 324 access point discovery mechanism. 326 It is intended that service: URLs be selected according to the 327 suitability of associated attributes. A client application may 328 obtain the URLs of several services of the same type and distinguish 329 the most preferable among them by means of their attributes. The 330 client will use the service: URL to bind directly to a service. 332 These attributes will be specified as shown with the "service- 333 template", described below. If a service: URL is stored by a client 334 or an agent representing a client, the agent SHOULD also keep track 335 of the attributes which characterize the service offered at the 336 network location indicated by the URL, and can use the service 337 template for additional information about those service attributes. 338 The registration of this attribute information is typically done 339 using the Service Location Protocol [10], although manual techniques 340 and other protocols may be possible. 342 3. Specifying A New Service Type 344 A Service Type defines the syntax for all URLs that will be 345 registered by services of the particular type. For instance, a 346 'Printer' service type is defined with service: URLs in the following 347 form: 349 service:printer://
/ 351 The service agent registering the printer service can be selected by 352 clients specifying the protocol which matches the protocol attribute 353 registered with the printer URL above. The attribute information can 354 be used to indicate other configuration details, optional features 355 available and characteristics (which may be relevent to a human user 356 or to a program.) 358 3.1. Service Type Specifications 360 Service Type specifications define the fields described in the 361 following subsections, and define the syntax of the service-part of 362 service: URLs of that service type. 364 3.1.1. Service Type 366 This is a string which will be prepended by the 'service:' scheme. 367 It may be a name which is entirely invented or be the same as a well 368 known service scheme. For example, service:http: might refer to a 369 HTTP server, whereas the http: scheme used in a URL generally refers 370 to a document. 372 The meaning of this service type must be fully described by service 373 type specification. A network protocol specification is often 374 included as one of the attributes associated with the service, and 375 may optionally be registered by some service agents as part of the 376 service: URL include in the service registration. 378 3.1.2. The service: 'url-path' information 380 This information is included in the URL in order to provide uniquely 381 identifying information. This mechanism is used in the examples 382 which follow in order to identify a mountable filesystem (using the 383 'nfs' service type) and an lpd print queue (as described above). 385 The syntax and interpretation of the url-path must accompany the 386 definition of a new Service Type. See section 3.3.3, describing the 387 mandatory "template.url-path rules" attribute. The url-path may be 388 very simple, or even entirely omitted except possibly a terminating 389 slash. See [4] for examples and general guidance. 391 3.1.3. Attributes 393 This information provides information about the service's 394 capabilities, characteristics and required client configuration. 395 Each attribute which is defined must have a default value and 396 definition of all values it can take. 398 An attribute may take one or more values. A keyword does not take 399 any values. Registration, deregistration and the use of attributes 400 in queries may be accomplished using Service Location Protocol, or 401 possibly other means beyond the scope of this document. 403 3.2. Specifying Attributes 405 Attributes are used to convey information about a given service for 406 purposes of differentiating different services of the same type. 407 They convey information to be used in the selection of which service 408 to bind to, either browsers or for use by a program. 410 Attributes may be encoded in different character sets and in 411 different languages. The procedure for doing this is described in 412 Section 9. 414 Attributes definitions have several components. 416 1. The first is a 'tag'. This is a string with certain encoding 417 rules. 419 2. Attribute descriptors (type and flags) 421 3. Possibly, a set of typed values. 423 4. Descriptive help text explaining necessary information about what 424 the attribute is 426 Attributes (but not keywords) may have one or more values. Values of 427 an attribute are typed, and must have the same type for each value if 428 the attribute is multivalued. The rules for typing and encoding of 429 attribute values is given in the rest of section 3.2. 431 3.2.1. Service Templates and attributes 433 Service Templates provide rules for attributes. They define: 435 - Which attributes are REQUIRED with every service registration of 436 a given service type, and which are OPTIONAL. 438 - The type of values possible for the attribute (e.g., STRING). 440 - Whether the attribute may take multiple values. 442 - Whether the attribute may take arbitrary values or only those 443 provided in the list. 445 - Whether the attribute may be translated to other languages or is 446 a 'literal', ie. not meant for human readability. 448 - Whether the service: URL can be be supplied in response to a 449 request that does not give a value for the attribute, when the 450 attribute is used as part of the registration for that service: 451 URL. 453 3.2.2. Service Templates String Encoding 455 Service templates are encoded in a simple form. They may be 456 translated to any language or character set, but the template used 457 for standardization MUST be encoded in ASCII [2] and be in English. 459 Between each attribute definition there is a blank line. The rules 460 for encoding attributes is given below. Reserved characters include 461 ";", "&", "=", ",", "*", "#", TAB, LF, and CR. Reserved characters 462 may be escaped. The escaped character is replaced by a character 463 sequence with no spaces. The digits are a decimal representation of 464 the character value to be replaced, in the character set used for the 465 attribute encoding. 467 Some attributes may take values only among those present in a 468 specified value list. A keyword has no value list included. Any 469 attribute or keyword definition may include help text which can be 470 used to provide interactive descriptions helpful to people browsing 471 the available services. This descriptive text is often used to 472 explain technical details about the attribute or about the values 473 which the attribute can take. 475 esc-char = "&" "#" 1*DIGIT ";" 477 The following special case should be noted: 479 - Commas are used to separate list elements (e.g., allowable 480 attribute values. To use a comma in attribute encodings, escape 481 the comma with , 483 Service Templates have the following ABNF [6] grammar: 485 NOTE that this grammar is not quite correct yet, because it 486 needs a lot of work on specifying the scheme-def. 488 template = scheme-props scheme-def attr-defs 489 schemeatrs = schemevers schemelang schemetype schemetext 490 schemevers = "Version" "=" 1*DIGIT "." 1*DIGIT 491 schemelang = "Language" "=" 2*2lower-alpha 492 schemetype = "Type" "=" *schemechar 493 schemechar = ALPHA / DIGIT / "-" / "_" / "$" / "+" / 494 "@" / "." / "|" / "<" / ">" / "~" 495 schemetext = "Scheme-description" "=" [help-text] 496 scheme-def = url-path-rules 497 ; Rules for constructing service: URLs: 498 ; The scheme-def part of the template will 499 ; be text describing the allowable format 500 ; of information in the url-path of the 501 ; service-part of the service scheme. 502 ; The and FAQ fields do not 503 ; require additional specification. 504 attr-defs = *(attr-def/keydef) 505 attr-def = tag "=" attrtail newline 506 keydef = keyword "=" "KEYWORD" newline 507 attrtail = type flags newline [value-list] [help-text] 508 value-list = 1#value newline 509 help-text = 1#help-line 510 ; This is a human readable description of 511 ; this attribute and its values. 512 help-line = *[white-sp] "#" *[ com-chars ] newline 513 tag = 1*attrchar 514 keyword = 1*attrchar 515 attrchar = 1*(schemechar / ":" 516 flags = ["M"] ["L"] ["X"] ["O"] 517 ; M means multiple values are allowed 518 ; L "Literal", values MUST NOT be translated 519 ; X means explicit match required 520 ; O "Optional", the attribute may be omitted 522 value = string / integer / boolean / opaque 523 type = "STRING" / "INTEGER" / "BOOLEAN" | 524 "OPAQUE" / "KEYWORD" 525 ; These strings are not to be translated. 527 string = safe-char *[safe-chars / SPACE] safe-char 529 integer = [-] 1*DIGIT 530 ; The integer MUST fall within the range of 531 ; values a 32 bit integer may take, ie. 532 ; -2147483648 to 2147483647. 534 boolean = "TRUE" / "FALSE" 535 ; These strings are not to be translated. 537 com-chars = safe-char / white-sp / "*" / "," / ";"/ "&" 539 safe-char = attrchar / " " / "!" / '"' / "%" / "'" / 540 "(" / ")" / "+" / "," / "-" / "." / "|" / 541 ":" / "=" / "?" / "[" / "]" / 542 "" / "/" / "" / " " 543 ; All ASCII printable characters are 544 ; included except ",", "&", "*" and "#". 546 white-sp = SPACE / TAB 547 rad64-char = ALPHA / DIGIT / "+" / "-" / white-sp 548 opaque = 1*DIGIT ":" 4*rad64-char 549 ; The digits define the original length of 550 ; the opaque value. The restricted character 551 ; string is the radix-64 encoding of the opaque 552 ; value. See [5], Section 5.2. 553 ; NOTE: White space is ignored in decoding 554 ; radix-64 values. 555 newline = CR / ( CR LF ) 556 ABNF should have some way of denoting a continuation 557 line! Otherwise, it is ambiguous whether a next line is a 558 continuation or starts with some bizarro nonterminal. 560 Note on the use of white space: 562 A string is considered to be a token in the case of a tag or 563 value. In this case, the string is 'trimmed'. White space 564 interior to a string token is left alone, while white space between 565 the tokens is removed. For example: 567 " some name = some value , another example " 569 would be trimmed to 571 "some name" '=' "some value" and "another example". 573 Notes on string matching: 575 Attribute tags and values may be used by some protocols for directory 576 look-up. In this case, the following rules should be applied for 577 string matching of attribute strings. 579 Decoding character escape and trimming white space MUST be performed 580 before string matching. In addition, string matching SHOULD be case 581 insensitive. 583 3.2.3. Attributes with multiple values 585 Attributes with multiple values must be defined so that the type of 586 each value is the same. Boolean attributes may not take multiple 587 values. 589 Attributes and values must be given in exactly the same order in 590 translated service templates. This will allow the service templates 591 to be used to translate attributes and values to other languages 592 (using service templates as look up tables.) 594 3.2.4. Grouping attribute values together in records 596 Some attributes may be related, which is to say, not independent. 597 Each configuration, for instance, might have a limitation and a best 598 use. If these were encoded in separate attributes, the dependency 599 would not be clear: 601 Configuration = A,B,C 602 Restriction = slow,large,unpredictable,low-priority 603 Best Use = cpu-intensive,batch-jobs,interactive-use 605 Which is slow, A, B or C? Are interactive jobs unpredictable? The 606 suggested convention is to choose one of the attributes ranges to be 607 the attribute base. Here, it will be the configuration. The others 608 attributes are, by conventions, extensions of this record. The 609 following makes all dependencies explicit: 611 Configuration-A.Restriction = slow,low-priority 612 Configuration-A.Best-Use = batch-jobs 613 Configuration-B.Restriction = unpredictable 614 Configuration-B.Best-Use = interactive-use 615 Configuration-C.Restriction = large 616 Configuration-C.Best-Use = cpu-intensive 618 Note that the use of such grouping is conventional, by use of the 619 dot as an character, and does not place any constraint on 620 the parsing mechanisms used by agents storing the visually related 621 attribute values. 623 3.3. Special attributes 625 Every service template must define the following attributes: 627 3.3.1. Service Type Language 629 This is a two letter code defining the language of the template [8]. 631 3.3.2. Version 633 The version of the Service Type template. A proposal starts at 0.0, 634 and the minor number increments once per revision. The Version 635 attribute has a string value of the form: 637 version = 1*DIGIT '.' 1*DIGIT 639 A standardized template starts at 1.0. Additions of attributes add 640 one to the minor number, where changes of definition or removal of 641 attributes or values adds one to the major number. See Section 4 for 642 more detail on how to use the Version attribute. 644 3.3.3. url-path rules 646 This is a text attribute which defines the semantics of the url path 647 of the service: URL of the given type. 649 The is of the form: 651 ///;FAQ 653 The description specifies additional information to locate 654 a service when the is not sufficient, and is a field 655 whose content that distinguishes URLs of a particular service type 656 from those of another service type. For instance, in the case of a 657 printer service: URL, the url-path will typically be a queue name, 658 but not in the case of a service: URL for any other service type. 660 4. A Process For Standardizing New Service Types 662 New Service Types can be suggested simply by providing a Service Type 663 template and a short description of the use for the service: URL. 664 This MUST have its 'Version' attribute set to "0.0" initially. 666 The minor version number will increment once with each change until 667 it achieves 1.0. There is no guarantee any version of the service 668 template will be backwards compatible before it reaches 1.0. 670 Once a service template has reached 1.0, the definition is "frozen" 671 for that version. New templates may be defined, of course, to refine 672 that definition, but they must follow these rules: 674 - Any new attribute defined for the template will increase the 675 minor version number by one. All other attributes for the 676 version must continue to be supported as before. A client which 677 supports 1.x can still use later versions of 1.y (where x