idnits 2.17.1 draft-ietf-svrloc-service-scheme-05.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-25) 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 3 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 41: '...ce: URL, the URL SHOULD be accompanied...' RFC 2119 keyword, line 42: '... the service. These attributes SHOULD...' RFC 2119 keyword, line 50: '... They SHOULD be used by administrati...' RFC 2119 keyword, line 181: '...en the service type name SHOULD either...' RFC 2119 keyword, line 236: '... The syntax of the service: URL MUST conform to [6]. The only...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1318 has weird spacing: '...sun.com char...' -- 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) == Unused Reference: '2' is defined on line 1257, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1766 (ref. '4') (Obsoleted by RFC 3066, RFC 3282) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1808 (ref. '6') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 1738 (ref. '7') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2052 (ref. '10') (Obsoleted by RFC 2782) -- No information found for draft-ietf-svrloc-advertise - is the name correct? -- Possible downref: Normative reference to a draft: ref. '11' ** Obsolete normative reference: RFC 2222 (ref. '12') (Obsoleted by RFC 4422, RFC 4752) == Outdated reference: A later version (-06) exists of draft-ietf-acap-spec-04 -- Unexpected draft version: The latest known version of draft-ietf-svrloc-lpr-scheme is -00, but you're referring to -01. (However, the state information for draft-ietf-svrloc-advertise is not up-to-date. The last update was unsuccessful) -- Possible downref: Normative reference to a draft: ref. '14' ** Obsolete normative reference: RFC 2044 (ref. '16') (Obsoleted by RFC 2279) Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 11 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 James Kempf 4 31 October 1997 Sun Microsystems 6 Service Templates and service: Schemes 7 draft-ietf-svrloc-service-scheme-05.txt 9 Status of This Memo 11 This document is a submission by the Service Location Working Group 12 of the Internet Engineering Task Force (IETF). Comments should be 13 submitted to the srvloc@corp.home.net mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at 24 any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check 28 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 29 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North 30 Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), 31 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 33 Abstract 35 The ''service:'' URL scheme name is used to define URLs (called 36 ''service: URLs'' in this document) that are primarily intended to be 37 used by the Service Location Protocol in order to distribute service 38 access information. These schemes provide an extensible framework 39 for client-based network software to obtain configuration information 40 required to make use of network services. When registering a 41 service: URL, the URL SHOULD be accompanied by a set of well-defined 42 attributes which define the service. These attributes SHOULD 43 convey configuration information to client software, or service 44 characteristics meaningful to end users. 46 This document describes a formal procedure for defining and 47 standardizing new service types and attributes for use with the 48 ''service:'' scheme. The formal descriptions of service types and 49 attributes are templates that are human and machine understandable. 50 They SHOULD be used by administrative tools to parse service 51 registration information and by client applications to provide 52 localized translations of service attribute strings. 54 Contents 56 Status of This Memo i 58 Abstract i 60 1. Introduction 2 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Service Location Protocol . . . . . . . . . . . . . . . . 4 64 2. Related work 4 66 3. Service URL Syntax and Semantics 4 67 3.1. Service URL Syntax . . . . . . . . . . . . . . . . . . . 4 68 3.2. Service URL Semantics . . . . . . . . . . . . . . . . . . 6 69 3.3. Use of service: URLs . . . . . . . . . . . . . . . . . . 7 70 3.4. Specifying the Service Type-Specific URL Syntax . . . . . 8 71 3.5. Accommodating Abstract Service Types . . . . . . . . . . 8 72 3.5.1. Advertising Abstract Service Types . . . . . . . 9 74 4. Syntax and Semantics of Service Type Specifications 10 75 4.1. Syntax of Service Type Templates . . . . . . . . . . . . 10 76 4.2. Semantics of Service Type Templates . . . . . . . . . . . 13 77 4.2.1. Definition of a Service Template . . . . . . . . 13 78 4.2.2. Service Type . . . . . . . . . . . . . . . . . . 14 79 4.2.3. Service Type Language . . . . . . . . . . . . . . 14 80 4.2.4. Version Number . . . . . . . . . . . . . . . . . 14 81 4.2.5. Description . . . . . . . . . . . . . . . . . . . 14 82 4.2.6. Syntax of the Service Type-specific URL Part . . 15 83 4.2.7. Attribute Definition . . . . . . . . . . . . . . 15 85 5. A Process For Standardizing New Service Types 19 87 6. IANA Considerations 20 89 7. Internationalization Considerations 21 90 7.1. Language Identification and Translation . . . . . . . . . 21 92 8. Security Considerations 22 94 A. Service Template Examples 22 95 A.1. ACAP . . . . . . . . . . . . . . . . . . . . . . . . . . 23 96 A.2. Abstract Service Template Example: Network-Management . 24 97 A.3. Concrete Service Template Example: Network-Management:SNMP 98 24 100 A.4. service: URLs and SLP . . . . . . . . . . . . . . . . . . 26 102 1. Introduction 104 This document describes a URL scheme, called service: URL, which 105 defines network access information for network services using a 106 formal notation. In addition it describes how to define a set of 107 attributes to associate with a service: URL. These attributes will 108 allow end users and programs to select between network services of 109 the same type that have different capabilities. The attributes 110 are defined in a template document that is readable by people and 111 machines. 113 A client uses attributes to select a particular service. Service 114 selection occurs by obtaining the service: URL that offers the right 115 configuration for the client. Service type templates define the 116 syntax of service: URLs for a particular service type, as well as the 117 attributes which accompany a service: URL in a service registration. 119 Templates are used for the following distinct purposes: 121 1. Standardization 123 The template is reviewed before it is standardized. Once it is 124 standardized, all versions of the template are archived by IANA. 126 2. Service Registration 128 Servers making use of the Service Location Protocol [15] register 129 themselves and their attributes. They use the templates to 130 generate the service registrations. In registering, the service 131 must use the specified values for its attributes. 133 3. Client presentation of Service Information 135 Client applications may display service information. The 136 template provides type information and explanatory text which may 137 be helpful in producing user interfaces. 139 4. Internationalization 141 Entities with access to the template for a given service type in 142 two different languages may translate between the two languages. 144 A service may register itself in more than one language using 145 templates, though it has been configured by an operator who 146 registered service attributes in a single language. 148 All grammar encoding follows the Augmented BNF (ABNF) [9] for syntax 149 specifications. 151 1.1. Terminology 153 This section introduces some terminology for describing service: 154 URLs. 156 service scheme 158 A URL scheme whose name starts with the string "service:" and 159 is followed by the service type name, constructed according to 160 the rules in this document. An example is "service:lpr:" for 161 the lpr print service [14]. 163 service: URL 165 A URL constructed according to the service scheme definition. 166 It typically provides at least the following: The name of an 167 access protocol, and an address locating this service. The 168 service: URL may include url path information specific to the 169 type of service, as well as attribute information encoded 170 according to the URL grammar. The service: URL is used by 171 the Service Location Protocol to register and discover the 172 location of services. It may be used by other protocols and in 173 documents as well. 175 service type 177 A name identifying the semantics by which the remainder of 178 the service: URL is to be understood. It may denote either a 179 particular network protocol, or an abstract service associated 180 with a variety of protocols. If the service type denotes a 181 particular protocol, then the service type name SHOULD either 182 be assigned the name of a particular well known port [3] 183 by convention or or be the Assigned Numbers name for the 184 service [1]. 186 abstract service type 188 A service type name which is associated with a variety of 189 different protocols. An example is given in Section A. 190 Section 3 discusses various ways that abstract types can be 191 accommodated. 193 service registration 195 A service: URL and optionally a set of attributes comprise 196 a service registration. This registration is made by or on 197 behalf of a given service. The URL syntax and attributes must 198 conform to the service template for the registered service. 200 service template 202 A formal description of the service attributes and service 203 scheme associated with a particular service type. 205 1.2. Service Location Protocol 207 The Service Location Protocol [15] allows service: URLs to be 208 registered and discovered, though service: URLs may be also used in 209 other contexts. 211 Client applications discover service registrations by issuing queries 212 for services of a particular type, specifying the attributes of 213 the service: URLs to return. Clients retrieve the attributes of a 214 particular service by supplying its service: URL. Attributes for all 215 service registrations of a particular type can also be retrieved. 217 Services may register themselves, or registrations may be made on 218 their behalf. These registrations contain a service: URL, and 219 possibly attributes and digital signatures. 221 2. Related work 223 The "Finding Stuff" work by Ryan Moats, Martin Hamilton, and 224 Paul Leach uses service: URLs to provide access information about 225 arbitrary network protocols through DNS [11]. DNS SRV Resource 226 Records are a mechanism which provides a way to obtain a service by 227 type for a given domain [10], without specifying which instance of 228 the service type meet particular requirements. 230 3. Service URL Syntax and Semantics 232 This section describes the syntax and semantics of service: URLs. 234 3.1. Service URL Syntax 236 The syntax of the service: URL MUST conform to [6]. The only 237 exception is that the field has been omitted from the 238 production, since plain text transmission of passwords is 239 now discouraged. Note that the syntax for the field depends 240 upon the service type definition. The field is the service 241 access point, and describes how to access the service. In addition, 242 although both upper case and lower case characters are recognized in 243 the field for convenience, the name is case-folded 244 into lower case. Service types are therefore not distinguished on 245 the basis of case, so, for example, "http" and "HTTP" designate the 246 same service type. This is consistent with general URL practice, as 247 outlined in [7]. 249 The ABNF for a service: URL is: 251 service: URL = "service:" service-type ":" sap 252 service-type = abstract-type ":" url-scheme / concrete-type 253 abstract-type = type-name [ "." naming-auth ] 254 concrete-type = protocol [ "." naming-auth ] 255 type-name = resname 256 naming-auth = resname 257 url-scheme = resname 258 ; A recognized URL scheme name, standardized 259 ; either through common practice or through 260 ; approval of a standards body. 261 resname = alpha [ 1*(alpha / digit / "+" / "-") ] 262 sap = "//" site [ url-part ] 263 site = [ [ user "@" ] hostport ] 264 hostport = host [ ":" port ] 265 host = hostname / hostnumber 266 hostname = *( domainlabel "." ) toplabel 267 alphanum = alpha / digit 268 domainlabel = alphanum / alphanum *[alphanum / "-"] alphanum 269 toplabel = alpha / alpha *[ alphanum / "-" ] alphanum 270 hostnumber = ipv4-number / ipv6-number 271 ipv4-number = 1*3digit 3("." 1*3digit) 272 ipv6-number = 32hex 273 3digit = digit digit digit 274 port = 1*digit 275 ; A port number must be included if the 276 ; protocol field does not have an IANA 277 ; assigned port number. 278 user = *[ uchar / ";" / "+" / "&" / "=" ] 279 url-part = [ url-path ] [ attr-list ] 280 url-path = 1 * ( "/" *xchar ) 281 ; Each service type must define its 282 ; own syntax consistent 283 ; with [6]. 284 attr-list = 1 * ( ";" attr-asgn ) 285 attr-asgn = attr-id / attr-id "=" attr-value 286 safe = "$" / "-" / "_" / "." / "~" 287 extra = "!" / "*" / "'" / "(" / ")" / "," / "+" 288 uchar = unreserved / escaped 289 xchar = unreserved / reserved / escaped 290 escaped = "%" hex hex 291 hex "a" / "b" / "c" / "d" / "e" / digit 292 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" 293 unreserved = alpha / digit / safe / extra 295 Certain characters must be escaped before use. To escape any 296 character, precede the two digits indicating its ASCII value by '%'. 298 3.2. Service URL Semantics 300 The service scheme-specific information following the "service:" 301 URL scheme identifier provides information necessary to access the 302 service. As described in the previous subsection, the form of a 303 service: URL is as follows: 305 service: URL = "service:" service-type ":" sap 307 where has the following form: 309 //addr-spec/url-path;attr-list 311 The field includes the field. As 312 discussed in Section 1, the can be either a concrete 313 protocol name, or an abstract type name. 315 The field includes a site specification (the 316 field) in the format specified by [6]. The field 317 is typically either a domain name (DNS) or an IP network protocol 318 address for the service, and possibly a port number. Note that use 319 of DNS hostnames is preferred for ease of renumbering. The 320 field can be null if other information in the service URL or service 321 attributes is sufficient to use the service. 323 The field allows more information to be provided (by way of 324 and ) that can uniquely locate the service or 325 resource if the is not sufficient for that purpose. 327 An field appears at the end of the field, 328 but is never required to exist in any service location registration. 329 The field is composed of a list of semicolon (";") 330 separated attribute assignments of the form: 332 attr-id "=" attr-value 334 or for keyword attributes: 336 attr-id 338 Attributes are part of service: URLs when the attributes are required 339 to access a particular service. For instance, an ACAP [13] service 340 might require that the client authenticate with it through Kerberos. 341 Including an attribute in the service registration allows the ACAP 342 client to make use of the correct SASL [12] authentication mechanism. 343 The ACAP server's registration might look like: 345 service:acap://some.where.net;authentication=KERBEROSV4 347 Note that there can be other attributes of an ACAP server which are 348 not be appropriate to include in the URL. For instance, the list 349 of users who have access to the server is useful for selecting an 350 ACAP server, but is not required for a client to use the registered 351 service. 353 Attributes associated with the service: URL are not typically 354 included in the service: URL. They are stored and retrieved using 355 other mechanisms. The service: URL is uniquely identified with a 356 particular service agent or resource, and is used when registering or 357 requesting the attribute information. The Service Location Protocol 358 specifies how such information SHOULD be registered by network 359 services and obtained by client software. 361 3.3. Use of service: URLs 363 The service: URL is intended to allow arbitrary client/server and 364 peer to peer systems to make use of a standardized dynamic service 365 access point discovery mechanism. 367 It is intended that service: URLs be selected according to the 368 suitability of associated attributes. A client application can 369 obtain the URLs of several services of the same type and distinguish 370 the most preferable among them by means of their attributes. The 371 client uses the service: URL to communicate directly to a service. 373 Attributes are specified with a formal service template syntax 374 described in Section 4. If a service: URL registration includes 375 attributes, the registering agent SHOULD also keep track of the 376 attributes which characterize the service. 378 Registrations can be checked against the formal attribute 379 specification defined in the template by the client or agent 380 representing the client. Service registration are typically done 381 using the Service Location Protocol [15] (SLP). SLP provides a 382 mechanism for service: URLs to be obtained dynamically, according to 383 the service's attributes. 385 It is also possible to obtain service: URLs from documents and using 386 other protocols. In this case, the URL may not be accompanied by 387 the service attributes. The context in which the URL appears SHOULD 388 make it clear, if possible, when the service is appropriate to use. 389 For example, in a mail message, a service might be recommended for 390 use when the user is in a branch office. Or, an HTML document might 391 include a service: URL as a pointer to a service, describing in text 392 what the service does and who is authorized to use it. 394 3.4. Specifying the Service Type-Specific URL Syntax 396 When a service type is specified, the specification includes the 397 definition of the syntax for all URLs that are registered by services 398 of that particular type. For instance, the "lpr" service type may be 399 defined with service: URLs in the following form: 401 service:printer:lpr://
/ 403 The section of the URL after the address of the printer: 405 "/" 407 is specific to the lpr service type and corresponds to the 408 field of the general service: URL syntax. This part is 409 specified when the lpr service type is specified. 411 3.5. Accommodating Abstract Service Types 413 An abstract service type is a service type that can be implemented by 414 a variety of different service agents. 416 In order to register an service: URL for an abstract service type the 417 'abstract-type' grammar rule described in section 3.1 is used. This 418 will result in a URL which includes enough information to use the 419 service, namely, the protocol, address and path information. Unlike 420 'concrete' service: URLs, however, the service type is not enough 421 to determine the service access. Rather, an abstract service type 422 denotes a class of service types. The following subsection discusses 423 this point in more detail. 425 3.5.1. Advertising Abstract Service Types 427 Some services may make use of several protocols that are in common 428 use and are distinct services in their own right. In these cases an 429 abstract service type is appropriate. What is essential is that all 430 the required information for the service is clearly defined. 432 For example, suppose a network service is being developed for 433 dynamically loading device drivers. The client requires the 434 following three pieces of information before it can successfully load 435 and instantiate the driver: 437 1. The protocol used to load the driver code, for example, "ftp", 438 "http" or "tftp" 440 2. A pathname identifying where the driver code is located, for 441 example "/systemhost/drivers/diskdrivers.drv", 443 3. The name of the driver, for example, "scsi". 445 The temptation is to form the first two items into a URL and embed 446 that into a service: URL. As an example which should be avoided, 448 service:ftp:/x3.bean.org/drivers/diskdrivers.drv;driver=scsi 450 is a service: URL which seems to indicate where to obtain the driver. 452 Rather, an abstract service-type SHOULD be used. The service type is 453 not "ftp", as the example indicates. Rather, it is "device-drivers". 454 The service: URL that should be used, consistent with the rules in 455 section [6], is the following: 457 service:device-drivers:ftp://x3.bean.org/drivers/diskdrivers.drv; 458 driver=scsi;platform=sys3.2-rs3000 460 Other URLs for the same service using other protocols are also 461 supported, as in: 463 service:device-drivers:tftp://x2.bean.org/vol3/disk/drivers.drv; 464 driver=scsi;platform=sys3.2-rs3000 466 service:device-drivers:http://www.bean.org/drivers/drivpak.drv; 467 driver=scsi;platform=sys3.2-rs3000 469 Using SLP, a search for the service type "device-drivers" may return 470 all of the three URLs listed above. The client selects the most 471 appropriate access protocol for the desired resource. 473 The fundamental requirement is that the abstract service type MUST 474 be well specified. This requirement is imposed so that program code 475 or human users have enough information to access the service. In 476 every case, a well-specified abstract type will include either an 477 access protocol and a network address where the service is available, 478 or an embedded URL for a standardized URL scheme that describes 479 how to access the service. In the example above, there are three 480 further requirements: A URL path is included for access protocols 481 indicating the document to download, and two attributes are included 482 to characterize the driver. 484 4. Syntax and Semantics of Service Type Specifications 486 Service type specifications are documents in a formal syntax defining 487 properties important to service registration. These properties are: 489 1. General information on the service type specification itself, 491 2. The syntax of the service type-specific part of the service URL, 493 3. The definition of attributes associated with a service. 495 The service type specification document is the service type template. 497 The following subsections describe the syntax and semantics of 498 service type templates. 500 4.1. Syntax of Service Type Templates 502 Service template documents are encoded in a simple form. They may be 503 translated into any language or character set, but the template used 504 for standardization MUST be encoded in UTF8 [16] and be in English. 506 A template document begins with a block of text assigning values to 507 five document identification items. The five identification items 508 can appear in any order within the block, but conventionally the 509 "type" item, which assigns the service type name, occurs at the very 510 top of the document in order to provide context for the rest of 511 the the document. The attribute definition item occurs after the 512 document identification items. 514 All items end with a blank line. The reserved characters are ";", 515 "%", "=", ",", "#", LF, and CR. Reserved characters MUST be escaped. 516 The escape sequence is the same as described in [6]. 518 The service template is encoded in a UTF8 character set, but 519 submitted as a part of an internet-draft, which is encoded in ASCII 520 characters. All characters which are outside of the ASCII range MUST 521 be escaped using the % HEX HEX syntax. For example, the letter e 522 accent aigue would be represented as "%c3%a9". Unfortunately, this 523 will detract from the readability of the service template in the 524 internet draft. Hopefully some public domain tools will emerge for 525 translating escaped UTF8 characters into humanly readable ones. 527 Values in value lists are separated by commas. A value list is 528 terminated by a newline not preceded by a comma. If the newline is 529 preceded by a comma, the value list is interpreted to continue onto 530 the next line. 532 Attribute identifiers, attribute type names, and flags are all 533 case insensitive. For ease of presentation, upper and lower case 534 characters can be used to represent these in the template document. 535 Newlines are significant in the grammar. They delimit one item from 536 another, as well as separating parts of items internally. 538 String values are considered to be a sequence of non-whitespace 539 tokens potentially with embedded whitespace, separated from each 540 other by whitespace. Commas delimit lists of strings. String values 541 are trimmed so as to reduce any sequence of white space interior to a 542 string to a single white space. Preceding or trailing white space is 543 removed. For example: 545 " some value , another example " 547 is trimmed to 549 "some value" and "another example". 551 Note that there can be no ambiguity in string tokenization because 552 values in value lists are separated by a comma. String tokens are 553 not delimited by double quotes (") as is usually the case with 554 programming languages. 556 Attribute tags and values are useful for directory look-up. In this 557 case, decoding of character escapes and trimming white space MUST 558 be performed before string matching. In addition, string matching 559 SHOULD be case insensitive. 561 Templates obey the following ABNF [9] grammar: 563 template = tem-attrs attr-defs 564 tem-attrs = schemetype schemevers schemelang 565 schemetext schemeurl 566 schemetype = "type" "=" scheme termdef 567 schemevers = "version" "=" version-no termdef 568 schemelang = "language" "=" isolang termdef 569 schemetext = "description" "=" newline desc-text termdef 570 schemeurl = "url-syntax" "=" newline url-bnf termdef 571 url-bnf = *[ com-chars ] 572 ; An ABNF describing the production 573 ; in the service: URL grammar of Section 3.1. 574 scheme = service-type [ "." naming-auth ] 575 service-type = scheme-name 576 naming-auth = scheme-name 577 scheme-name = alpha [1*schemechar] [ "." 1*schemechar ] 578 schemechar = alpha / digit / "-" / "+" / 579 version-no = 1*digit "." 1*digit 580 isolang = 2*3lower-alpha ;see [4] 581 desc-text = *[ com-chars ] 582 ; A block of free-form text for reading by 583 ; people describing the service in a short, 584 ; informative manner. 585 termdef = newline newline 586 attr-defs = *( attr-def / keydef ) 587 attr-def = id "=" attrtail 588 keydef = id "=" "keyword" newline [help-text] newline 589 attrtail = type flags newline [value-list] [help-text] 590 [value-list] newline 591 id = 1*attrchar 592 type = "string" / "integer" / "boolean" / "opaque" 593 flags = ["m"/"M"] ["l"/"L"] ["o"/"O"] ["x"/"X"] 594 value-list = value newline / value "," value-list / 595 value "," newline value-list 596 help-text = 1*( "#" help-line ) 597 ; A block of free-form text for reading by 598 ; people describing the attribute and 599 ; its values. 600 help-line = *[ com-chars ] newline 601 attrchar = schemechar / ":" / "_" / "$" / "~" / "@" / "." / 602 "|" / "<" / ">" / "*" / "&" 603 value = string / integer / boolean / opaque 604 string = safe-char *[safe-char / white-sp] safe-char 605 integer = [ "+" | "-" ] 1*digit 606 boolean = "true" / "false" 607 opaque = 1*digit ":" 4*radix64-char 608 ; The digits define the original length of 609 ; the opaque value. The restricted character 610 ; string is the radix-64 encoding of the 611 ; opaque value( [8], Sect. 6.8.) 612 ; Newlines are ignored in decoding radix-64 613 ; values. 614 com-chars = safe-char / white-sp / "," / ";"/ "%" 615 safe-char = attrchar / escaped / " " / "!" / '"' / "'" / 616 "|" / "(" / ")" / "+" / "-" / "." / ":" / 617 "=" / "?" / "[" / "]" / "{" / "/" / "{" / 618 "$" 619 ; All UTF8 printable characters are 620 ; included except ",", "%", ";", and "#". 621 escaped = "%" hex hex 622 hex = digit / "A" / "B" / "C" / "D" / "E" / 623 "a" / "b" / "c" / "d" / "e" 624 white-sp = space / tab 625 newline = CR / ( CR LF ) 627 4.2. Semantics of Service Type Templates 629 The service type template defines the service attributes and service: 630 URL syntax for a particular service type. The attribute definition 631 includes the attribute type, default values, allowed values and other 632 information. 634 4.2.1. Definition of a Service Template 636 There are six items included in the service template. The semantics 637 of each item is summarized below. 639 - type 641 The scheme name of the service scheme. The scheme name consists 642 of the service type name and an optional naming authority name, 643 separated from the service type name by a period. See 4.2.2 for 644 the conventions governing service type names. 646 - version 648 The version number of the service type specification. 650 - language 652 The language of the service type specification. 654 - description 656 A description of the service suitable for inclusion in text read 657 by people. 659 - url-syntax 661 The syntax of the service type-specific URL part of the service: 662 URL. 664 - attribute definitions 666 A collection of zero or more definitions for attributes 667 associated with the service in service registrations. 669 Each of the following subsections deals with one of these items. 671 4.2.2. Service Type 673 The service scheme consists of the service type name and an optional 674 naming authority name separated from the service type name by a 675 period. The service scheme is a string that is appended to the 676 'service:' URL scheme identifier, and is the value of the "type" 677 item in the template document. If the naming authority name is 678 absent it is assumed to be IANA. 680 4.2.3. Service Type Language 682 The service type language is a RFC 1766 Language Tag defining the 683 language of the template [4] and is the value of the "language" item. 685 4.2.4. Version Number 687 The version number of the service type template is the value of the 688 "version" item. A draft proposal starts at 0.0, and the minor number 689 increments once per revision. A standardized template starts at 1.0. 690 Additions of optional attributes add one to the minor number, and 691 additions of required attributes, changes of definition, or removal 692 of attributes add one to the major number. The intent is that an 693 old service template still accurately, if incompletely, defines the 694 attributes of a service registration if the template only differs 695 from the registration in its minor version. See Section 5 for more 696 detail on how to use the version attribute. 698 4.2.5. Description 700 The description is a block of text readable by people in the language 701 of the template and is the value of the "description" item. It 702 should be sufficient to identify the service to human readers and 703 provide a short, informative description of what the service does. 705 If the service type corresponds to a particular protocol, the 706 protocol specification must be cited here. The protocol need not be 707 a standardized protocol. The template might refer to a proprietary 708 specification, and refer the reader of the template to a contact 709 person for further information. 711 4.2.6. Syntax of the Service Type-specific URL Part 713 The syntax of the service type-specific part of the service: 714 URL is provided in the template document as the value of the 715 "url-syntax" item. The field of the service: URL is 716 designed to provide additional information to locate a service when 717 the field is not sufficient. The field 718 distinguishes URLs of a particular service type from those of another 719 service type. For instance, in the case of the lpr service type, the 720 must include the queue name [14], but other service types 721 may not require this information. 723 The syntax for the field MUST accompany the definition 724 of a new service type, unless the URL scheme has already been 725 standardized and is not a service: URL. The syntax is included in the 726 template document as an ABNF [9] following the rules for URL syntax 727 described in [6]. There is no requirement for a service scheme to 728 support a . The field can be very simple, 729 or even omitted. If the URL scheme has already been standardized, 730 the "url-syntax" item SHOULD include a reference to the appropriate 731 standardization documents. Abstract service types may defer this 732 field to the template documents describing their concrete instances. 734 4.2.7. Attribute Definition 736 The bulk of the template is typically devoted to defining service 737 type-specific attributes. An attribute definition precisely 738 specifies the attribute's type, other restrictions on the attribute 739 (whether it is multi-valued, optional, etc), some text readable by 740 people describing the attribute, and lists of default and allowed 741 values. The only required information is the attribute's type, the 742 rest are optional. Registration, deregistration and the use of 743 attributes in queries can be accomplished using the Service Location 744 Protocol [15] or other means, and discussion of this is beyond the 745 scope of the document. 747 Attributes are used to convey information about a given service for 748 purposes of differentiating different services of the same type. 749 They convey information to be used in the selection of a particular 750 service to establish communicate with, either through a program 751 offering a human interface or programmatically. Attributes can be 752 encoded in different character sets and in different languages. The 753 procedure for doing this is described in Section 7. 755 An attribute definition begins with the specification of the 756 attribute's identifier and ends with a single empty line. Attributes 757 definitions have five components (in order of appearance in a 758 definition): 760 1. An attribute identifier which acts as the name of the attribute, 762 2. Attribute descriptors (type and flags), 764 3. An optional list of values which are assigned to the attribute by 765 default, 767 4. An optional block of text readable by people providing a short, 768 informative description of the attribute, 770 5. An optional list of allowed values which restrict the value or 771 values the attribute can take on. 773 4.2.7.1. The Attribute Identifier 775 An attribute definition starts with the specification of the 776 attribute's identifier. The attribute's identifier functions as the 777 name of the attribute. Note that the characters used to compose an 778 attribute identifier are restricted to those characters considered 779 unrestricted for inclusion in a URL according to [6]. The reason 780 is that services can display prominent attributes in their service: 781 URL registrations. Each attribute identifier must be unique in the 782 template. Since identifiers are case folded, upper case and lower 783 case characters are the same. 785 4.2.7.2. The Attribute Type 787 Attributes can have one of five different types: string, integer, 788 boolean, opaque, or keyword. The attribute's type specification is 789 separated from the attribute's identifier by an equal sign ("=") and 790 follows the equal sign on the same line. The string, signed integer, 791 and boolean types have the standard programming language or database 792 semantics. Integers are restricted to those signed values that can 793 be represented in 32 bits. The character set used to represent 794 strings is not specified at the time the template is defined, but 795 rather is determined by the service registration. Booleans have the 796 standard syntax. Opaques are radix64 numbers [8] that can be used 797 to represent any other kind of data. Keywords are attributes that 798 have no characteristics other than their existence (and possibly the 799 descriptive text in their definition). 801 Keyword and boolean attributes impose restrictions on the following 802 parts of the attribute definition. Keyword attribute definitions 803 MUST have no flag information following the type definition, nor any 804 default or allowed values list. Boolean attributes are single value 805 only, i.e., multi-valued boolean attributes are not allowed. 807 4.2.7.3. Attribute Flags 809 Flags determine other characteristics of an attribute. With the 810 exception of keyword attributes, which may not have any flags, 811 flags follow the attribute type on the same line as the attribute 812 identifier, and are separated from each other by whitespace. Flags 813 may appear in any order after the attribute type. Other information 814 must not follow the flags, and only one flag identifier of a 815 particular flag type is allowed per attribute definition. 817 The semantics of the flags are as follows: 819 - o or O 821 Indicates that the attribute is optional. If this flag is 822 missing, the attribute is required in every service registration. 824 - m or M 826 Indicates that the attribute can take on multiple values. If 827 this flag is present, every value in a multi-valued attribute 828 has the same type as the type specified in the type part of the 829 attribute definition. Boolean attributes must not include this 830 flag. 832 - l or L 834 Indicates that attribute is literal, i.e. is not meant to be 835 translated into other languages. If this flag is present, the 836 attribute is not considered to be readable by people and should 837 not be translated when the template is translated. See Section 7 838 for more information about translation. 840 - x or X 842 Indicates that clients MUST specify the attribute and a value in 843 a service query in order to narrowly focus which service: URLs 844 are returned. The query will be rejected by DA's that utilize 845 templates if the attribute is not included, regardless of whether 846 the other attributes match. 848 The values for multivalued attributes are an unordered set. 849 Deletions of individual values from a multivalued attribute are not 850 supported, and deletion of the attribute causes the entire set of 851 values to be removed. 853 4.2.7.4. Default Value or List 855 If the attribute definition includes a default value or, in the 856 case of multivalued attributes, a default values list, it begins 857 on the second line of the attribute definition and continues 858 over the following lines until a line ends without a comma. As a 859 consequence, newlines cannot be embedded in values unless escaped. 860 See Section 3.1. 862 Particular attribute types and definitions restrict the default 863 values list. Keyword attributes must not have a list of defaults. 864 If an optional attribute's definition has an allowed values list, 865 then a default value or list is not optional but required. The 866 motivation for this is that defining an attribute with an allowed 867 values list is meant to restrict the values the attribute can take 868 on, and requiring a default value or list assures that the default 869 value is a member of the given set of allowed values. 871 The default value or list indicates what values the attribute is 872 given if no values are assigned to the attribute when a service 873 is registered. If an optional attribute's definition includes no 874 default value or list, the following defaults are assigned: 876 1. String values are assigned the empty string, 878 2. Integer values are assigned zero, 880 3. Boolean values are assigned false, 882 4. Opaque values are assigned a byte array containing no values, 884 5. Multi-valued attributes are initialized with a single value. 886 For purposes of translating nonliteral attributes, the default values 887 list is taken to be an ordered set, and translations MUST maintain 888 that order. 890 4.2.7.5. Descriptive Text 892 Immediately after the default values list, if any, a block of 893 descriptive text SHOULD be included in the attribute definition. 894 This text is meant to be readable by people, and should include 895 a short, informative description of the attribute. It may also 896 provide additional information, such as a description of the allowed 897 values. This text is primarily designed for display by interactive 898 browsing tools. The descriptive text is set off from the surrounding 899 definition by a crosshatch character ("#") at the beginning of 900 the line. The text should not, however, be treated as a comment 901 by parsing and other tools, since it is an integral part of the 902 attribute definition. Within the block of descriptive text, the text 903 is transferred verbatim, including indentation and line breaks, so 904 any formatting is preserved. 906 4.2.7.6. Allowed Values List 908 Finally, the attribute definition concludes with an optional 909 allowed values list. The allowed values list, if any, follows the 910 descriptive text, or, if the descriptive text is absent, the initial 911 values list. The syntax of the allowed values list is identical to 912 that of the initial values list. The allowed values list is also 913 terminated by a line that does not end in a comma. If the allowed 914 values list is present, assignment to attributes is restricted to 915 members of the list. 917 As with the default values list, the allowed values list is also 918 considered to be an ordered set for purposes of translation. 920 4.2.7.7. Conclusion of An Attribute Definition 922 An attribute definition concludes with a single empty line. 924 5. A Process For Standardizing New Service Types 926 New service types can be suggested simply by providing a service type 927 template and a short description about how to use the service. The 928 template MUST have its "version" template attribute set to 0.0. 930 The minor version number increments once with each change until it 931 achieves 1.0. There is no guarantee any version of the service 932 template is backward compatible before it reaches 1.0. 934 Once a service template has reached 1.0, the definition is "frozen" 935 for that version. New templates must be defined, of course, to 936 refine that definition, but the following rules must be followed: 938 - Any new optional attribute defined for the template increases 939 the minor version number by one. All other attributes for the 940 version must continue to be supported as before. A client which 941 supports 1.x can still use later versions of 1.y (where x "." "." 986 Each of these fields are defined in Section 3. They correspond 987 to the values of the template fields "type", "version" and 988 "lang". The files for the example templates in this document 989 are called "acap.0.0.en", "network-management.0.0.en" and 990 "network-management:snmp.0.0.en". See Section A. 992 No Internet Draft describing a service type template will be accepted 993 unless it includes a security considerations section and contact 994 information for the template document author. 996 The IANA will maintain a registry containing both the service type 997 templates, and the template description document containing the 998 service type template, including all previous versions. The IANA 999 will receive notice by email from the reviewers, which will contain a 1000 reference to the Internet Draft that contains the service template. 1001 This Internet Draft will be edited to remove the Internet Draft 1002 headers and replace them with a simple header stating "This document 1003 contains a Service Type Template." 1005 Should any trademark or copyright issues arise due to the naming of 1006 the Service Type or attributes in the Service Template, the offending 1007 names may have to be changed. The owner of the trademark may 1008 demand that this be done. The filer of the Template that requires 1009 renaming will decide the new names to use. If such issues arise, 1010 the committee of reviewers in consultation with the IESG directorate 1011 will proceed to satisfy these conditions. The IANA should simply 1012 notify the committee and they will pursue the action: The IANA is 1013 not expected to resolve trademark issues with Service Type templates. 1015 7. Internationalization Considerations 1017 The service: URL must be encoded using the rules set forth in [6]. 1018 The character set encoding is limited to specific ranges within the 1019 US-ASCII character set [5]. 1021 The template is encoded in UTF8 characters. 1023 7.1. Language Identification and Translation 1025 The language used in attribute strings should be identified using the 1026 "language" template item as defined by [4]. 1028 A program can translate a service registration from one language to 1029 another provided it has both the template of the language for the 1030 registration and the template of the desired target language. All 1031 standardized attributes are in the same order in both templates. 1032 All non-arbitrary strings, including the descriptive help text, is 1033 directly translatable from one language to another. Non-literal 1034 attribute definitions, attribute identifiers, attribute type names, 1035 attribute flags, and the boolean constants "true" and "false" are 1036 never translated. Translation of attribute identifiers is prohibited 1037 because, as with domain names, they can potentially be part of a 1038 service: URL and therefore their character set is restricted. In 1039 addition, as with variable identifiers in programming languages, they 1040 could become embedded into program code. 1042 All strings used in attribute values are assumed translatable unless 1043 explicitly defined as being literal, so that best effort translation 1044 (see below) does not modify strings which are meant to be interpreted 1045 by a program, not a person. 1047 There are two ways to go about translation: standardization and best 1048 effort. 1050 When the service type is standardized, more than one document can 1051 be submitted for review. One service type description is approved 1052 as a master, so that when a service type template is updated in one 1053 language, all the translations (at least eventually) reflect the same 1054 semantics. 1056 If no document exists describing the standard translation of the 1057 service type, a 'best effort' translation for strings should be done. 1059 8. Security Considerations 1061 Service type templates provide information that is used to interpret 1062 information obtained by the Service Location Protocol. If these 1063 templates are modified or false templates are distributed, services 1064 may not correctly register themselves, or clients might not be able 1065 to interpret service information. 1067 The service: URLs themselves specify the service access point and 1068 protocol for a particular service type. These service: URLs could 1069 be distributed and indicate the location of a service other than 1070 that normally want to used. The Service Location Protocol [15] 1071 distributes service: URLs and has an authentication mechanism that 1072 allows service: URLs of registered services to be signed and for the 1073 signatures to be verified by clients. 1075 Each Service Template will include a security considerations section 1076 which will describe security issues with using the service scheme for 1077 the specific Service Type. 1079 A. Service Template Examples 1081 The text in the template example sections is to be taken as being a 1082 single file. 1084 The ACAP example shows how to use service templates for an 1085 application that has very few attributes. Clients request the ACAP 1086 server where their user data is located by including their user name 1087 as the value of the user attribute. 1089 The Network-Management example shows how abstract service types are 1090 defined and how a corresponding concrete instance is defined. A 1091 system might support any of several Network-Management services. 1092 Here we give only one concrete instance of the abstract type. It is 1093 not necessary to register concrete templates for an abstract service 1094 type if the abstract service type template is completely clear as to 1095 what possible values can be used as a concrete type, and what their 1096 interpretation is. 1098 A.1. ACAP 1100 -------------------------template begins here----------------------- 1101 type=ACAP 1103 version=0.0 1105 lang=en 1107 description= 1108 The ACAP service URL provides the location of an ACAP service. 1110 url-syntax= 1111 url-path= ; There is no URL path defined for an ACAP URL. 1113 users= string M L O 1114 # The list of all users which the ACAP server supports. 1116 groups= string M L O 1117 # The list of all groups which the ACAP server supports. 1118 --------------------------template ends here------------------------ 1120 The Internet Draft describing the ACAP scheme template must indicate 1121 contact information and security considerations, e.g., 1123 contact="Erik Guttman" 1125 security considerations= 1126 If the USER and GROUPS attributes are included a 1127 possibility exists that the list of identities for users or groups 1128 can be discovered. This information would otherwise be difficult 1129 to discover. 1131 A.2. Abstract Service Template Example: Network-Management 1133 The Internet Draft for the service type template contains the 1134 following text: 1136 -------------------------template begins here----------------------- 1137 type=Network-Management 1139 version=0.0 1141 lang=en 1143 description= 1144 This is an abstract service type. The purpose of the network- 1145 management service type is to organize into a single category 1146 information crucial to properly managing networked hosts. This 1147 will allow all network-management services of a host, as well 1148 as basic host configuration to be obtained by a single query 1149 using SLP. 1151 url-syntax= 1152 url-path= ; Depends on the concrete service type. 1153 ; See these templates. 1154 --------------------------template ends here------------------------ 1156 In addition, the following format might be used for the needed 1157 contact and security considerations information. 1158 .......... 1160 contact="Erik Guttman" 1162 security considerations= 1163 See the security considerations of the concrete service types. 1165 A.3. Concrete Service Template Example: Network-Management:SNMP 1167 -------------------------template begins here----------------------- 1168 type=service:network-management:snmp 1170 version=0.0 1172 lang=en 1174 description= 1175 The 'service:network-management:SNMP:' URL provides information 1176 about the SNMP manageability of a given host. Namely, if this 1177 URL exists for a host (denoted by the in the URL,) 1178 the host supports SNMP. The path contains an enumeration of 1179 the MIB groups that are supported by the host. The OID "1.3.6.1." 1180 is assumed as a prefix to each of the OID terms below. 1182 url-syntax= 1183 url-path = ( [port-list] [comm-string] [oid-list]) 1184 ; None of the attributes listed in the URL path 1185 ; are required. They MAY be included. 1186 port-list = ";ports=" port-list 1187 ports = port / port "," ports 1188 ; See the Service URL production rule. 1189 ; This field is defined as an attribute, below. 1190 comm-string = ";read-community-string=" 1*uchar 1191 ; See the Service URL production rule. 1192 ; This field is defined as an attribute, below. 1193 oid-list = ";oids=" oids 1194 ; This field is defined as an attribute, below. 1195 oids = oid / oid "," oids 1196 oid = DIGIT [ "." (DIGIT ".") DIGIT] 1198 ports=integer M L 1199 161 1200 # This attribute must be included. It lists all ports on which 1201 # SNMP Agents are listening. 1203 read-community-string=string L O 1204 # The read community string may be included as an attribute of 1205 # a service:network-managment:snmp: URL. This is useful in 1206 # cases where the community string is PUBLIC and ease of access 1207 # to the SNMP Agent is desired. See the 'security considerations.' 1209 oid=string M L O 1210 # This attribute identifies a list of 'top level' MIB groups. 1211 # This is entirely optional, as such values can be obtained 1212 # directly using SNMP. The value of including this information 1213 # in a service:network-managment:snmp: URL is that it will save 1214 # the Manager time; the MIB information can be obtained along 1215 # with the URL without requiring additional sequential requests 1216 # being sent to the managed system. 1217 --------------------------template ends here------------------------ 1219 ......... 1221 contact="Erik Guttman" 1223 security considerations= 1224 The read-community-string MUST only be included if the value 1225 of this string is considered to be public. If this attribute 1226 is included, absolutely anyone may access the SNMP Agent and 1227 get information from it. This may be desirable in some cases. 1228 If this string is considered confidential information, the 1229 read-community-string MUST NOT be included in the URL path 1230 nor in service registrations of the URL made through SLP or 1231 other protocols. 1233 A.4. service: URLs and SLP 1235 A user with an ACAP enabled email client application should not 1236 be bothered with knowing the address of their ACAP server. The 1237 mail client program can use SLP to obtain the ACAP service: URL 1238 automatically, say 'service:acap://server1.nosuch.org', by issuing 1239 a Service Request. In the event that this ACAP server failed, the 1240 Email client can issue the same service request again to find the 1241 backup ACAP server, say 'service:acap://server2.nosuch.org'. In both 1242 cases, the service: URL conforms to the ACAP service template as do 1243 the associated attributes (user and group.) 1245 An SNMP based network Manager can use SLP to obtain 1246 service:network-management:SNMP URLs. This allows the network 1247 Manager to proceed to manage the hosts identified by these URLs 1248 without having to scan networks one address at a time, etc. SLP 1249 provides the capability to send multicast or directed broadcasts to 1250 obtain this information from every managed host. 1252 References 1254 [1] Protocol and service names, October 1994. 1255 ftp://ftp.isi.edu/in-notes/iana/assignments/service-names. 1257 [2] Address family numbers, October 1995. 1258 ftp://ftp.isi.edu/in-notes/iana/assignments/address-family-numbers. 1260 [3] Port numbers, July 1997. 1261 ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers. 1263 [4] H. Alvestrand. Tags for the Identification of Languages. RFC 1264 1766, March 1995. 1266 [5] ANSI. Coded Character Set -- 7-bit American Standard code for 1267 Information Interchange. X3.4-1986, 1986. 1269 [6] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource 1270 Locators (URL): Generic Syntax and Semantics. RFC1738 as 1271 amended by RFC1808 1273 [7] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource 1274 Locators (URL). RFC 1738, December 1994. 1276 [8] N. Freed and N. Borenstein. Multipurpose Internet Mail 1277 Extensions (MIME) Part One: Format of Internet Message Bodies. 1278 RFC 2045, November 1996. 1280 [9] D. Crocker and P Overell. Augmented BNF for Syntax 1281 Specifications: ABNF. draft-ietf-drums-abnf-04.txt, September 1282 1997. (work in progress). 1284 [10] A. Gulbrandsen and P. Vixie. A DNS RR for specifying the 1285 location of services (DNS SRV). RFC 2052, October 1996. 1287 [11] R. Moats and M. Hamilton. Finding Stuff (Providing information 1288 to support service discovery). draft-ietf-svrloc-advertise-00.txt, 1289 February 1997. (work in progress). 1291 [12] J. Myers. Simple Authentication and Security Layer (SASL). RFC 1292 2222, October 1997. 1294 [13] J. G. Myers. ACAP -- Application Configuration Access Prototol. 1295 draft-ietf-acap-spec-04.txt, June 1997. (work in progress). 1297 [14] Pete St. Pierre. Definition of lpr: URLs for use with Service 1298 Location. draft-ietf-svrloc-lpr-scheme-01.txt, November 1997. 1299 (work in progress). 1301 [15] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 1302 Location Protocol. RFC 2165, July 1997. 1304 [16] F. Yergeau. UTF-8, a transformation format of unicode and ISO 1305 10646. RFC 2044, October 1996. 1307 Authors' Addresses 1309 Questions about this memo can be directed to: 1311 Erik Guttman Charles E. Perkins James Kempf 1312 Sun Microsystems Sun Microsystems Sun Microsystems 1313 Bahnstr. 2 901 San Antonio Rd. 901 San Antonio Rd. 1314 74915 Waibstadt Palo Alto, CA, 94303 Palo Alto, CA, 94303 1315 Germany USA USA 1316 +49 7263 911484 1 650 786 6464 1 650 786 5890 1317 1 650 786 6445 (fax) 1 650 786 6445 (fax) 1318 erik.guttman@sun.com charles.perkins@sun.com james.kempf@sun.com