idnits 2.17.1 draft-ietf-svrloc-service-scheme-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 2 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 42: '...ce: URL, the URL SHOULD be accompanied...' RFC 2119 keyword, line 43: '... the service. These attributes SHOULD...' RFC 2119 keyword, line 51: '... They SHOULD be used by administrati...' RFC 2119 keyword, line 183: '...en the service type name SHOULD either...' RFC 2119 keyword, line 238: '... The syntax of the service: URL MUST conform to [5]. The only...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1352 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1766 (ref. '3') (Obsoleted by RFC 3066, RFC 3282) -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-09) exists of draft-fielding-url-syntax-05 -- Possible downref: Normative reference to a draft: ref. '5' ** Obsolete normative reference: RFC 1738 (ref. '6') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2052 (ref. '9') (Obsoleted by RFC 2782) == Outdated reference: A later version (-11) exists of draft-ietf-svrloc-discovery-05 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-12) exists of draft-myers-auth-sasl-11 == Outdated reference: A later version (-06) exists of draft-ietf-acap-spec-04 -- Possible downref: Normative reference to a draft: ref. '13' ** Obsolete normative reference: RFC 2044 (ref. '15') (Obsoleted by RFC 2279) Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Location Working Group Erik Guttman 3 INTERNET DRAFT Charles Perkins 4 James Kempf 5 21 November 1997 Sun Microsystems 7 Service Templates and service: Schemes 8 draft-ietf-svrloc-service-scheme-06.txt 10 Status of This Memo 12 This document is a submission by the Service Location Working Group 13 of the Internet Engineering Task Force (IETF). Comments should be 14 submitted to the srvloc@corp.home.net mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check 29 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 30 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North 31 Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), 32 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 34 Abstract 36 The ''service:'' URL scheme name is used to define URLs (called 37 ''service: URLs'' in this document) that are primarily intended to be 38 used by the Service Location Protocol in order to distribute service 39 access information. These schemes provide an extensible framework 40 for client-based network software to obtain configuration information 41 required to make use of network services. When registering a 42 service: URL, the URL SHOULD be accompanied by a set of well-defined 43 attributes which define the service. These attributes SHOULD 44 convey configuration information to client software, or service 45 characteristics meaningful to end users. 47 This document describes a formal procedure for defining and 48 standardizing new service types and attributes for use with the 49 ''service:'' scheme. The formal descriptions of service types and 50 attributes are templates that are human and machine understandable. 51 They SHOULD be used by administrative tools to parse service 52 registration information and by client applications to provide 53 localized translations of service attribute strings. 55 Contents 57 Status of This Memo i 59 Abstract i 61 1. Introduction 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Service Location Protocol . . . . . . . . . . . . . . . . 4 65 2. Related work 4 67 3. Service URL Syntax and Semantics 4 68 3.1. Service URL Syntax . . . . . . . . . . . . . . . . . . . 4 69 3.2. Service URL Semantics . . . . . . . . . . . . . . . . . . 6 70 3.3. Use of service: URLs . . . . . . . . . . . . . . . . . . 7 71 3.4. Specifying the Service Type-Specific URL Syntax . . . . . 8 72 3.5. Accommodating Abstract Service Types . . . . . . . . . . 8 73 3.5.1. Advertising Abstract Service Types . . . . . . . 9 75 4. Syntax and Semantics of Service Type Specifications 10 76 4.1. Syntax of Service Type Templates . . . . . . . . . . . . 10 77 4.2. Semantics of Service Type Templates . . . . . . . . . . . 13 78 4.2.1. Definition of a Service Template . . . . . . . . 13 79 4.2.2. Service Type . . . . . . . . . . . . . . . . . . 14 80 4.2.3. Service Type Language . . . . . . . . . . . . . . 14 81 4.2.4. Version Number . . . . . . . . . . . . . . . . . 14 82 4.2.5. Description . . . . . . . . . . . . . . . . . . . 14 83 4.2.6. Syntax of the Service Type-specific URL Part . . 15 84 4.2.7. Attribute Definition . . . . . . . . . . . . . . 15 86 5. A Process For Standardizing New Service Types 19 88 6. IANA Considerations 20 90 7. Internationalization Considerations 21 91 7.1. Language Identification and Translation . . . . . . . . . 21 93 8. Security Considerations 22 95 A. Service Template Examples 23 96 A.1. ACAP . . . . . . . . . . . . . . . . . . . . . . . . . . 23 97 A.2. Abstract Service Template Example: Network-Management . 24 98 A.3. Concrete Service Template Example: Network-Management:SNMP 99 24 100 A.4. service: URLs and SLP . . . . . . . . . . . . . . . . . . 26 102 B. Full Copyright Statement 27 104 1. Introduction 106 This document describes a URL scheme, called service: URL, which 107 defines network access information for network services using a 108 formal notation. In addition it describes how to define a set of 109 attributes to associate with a service: URL. These attributes will 110 allow end users and programs to select between network services of 111 the same type that have different capabilities. The attributes 112 are defined in a template document that is readable by people and 113 machines. 115 A client uses attributes to select a particular service. Service 116 selection occurs by obtaining the service: URL that offers the right 117 configuration for the client. Service type templates define the 118 syntax of service: URLs for a particular service type, as well as the 119 attributes which accompany a service: URL in a service registration. 121 Templates are used for the following distinct purposes: 123 1. Standardization 125 The template is reviewed before it is standardized. Once it is 126 standardized, all versions of the template are archived by IANA. 128 2. Service Registration 130 Servers making use of the Service Location Protocol [14] register 131 themselves and their attributes. They use the templates to 132 generate the service registrations. In registering, the service 133 must use the specified values for its attributes. 135 3. Client presentation of Service Information 137 Client applications may display service information. The 138 template provides type information and explanatory text which may 139 be helpful in producing user interfaces. 141 4. Internationalization 143 Entities with access to the template for a given service type in 144 two different languages may translate between the two languages. 146 A service may register itself in more than one language using 147 templates, though it has been configured by an operator who 148 registered service attributes in a single language. 150 All grammar encoding follows the Augmented BNF (ABNF) [8] for syntax 151 specifications. 153 1.1. Terminology 155 This section introduces some terminology for describing service: 156 URLs. 158 service scheme 160 A URL scheme whose name starts with the string "service:" and 161 is followed by the service type name, constructed according to 162 the rules in this document. An example is "service:lpr:" for 163 the lpr print service [13]. 165 service: URL 167 A URL constructed according to the service scheme definition. 168 It typically provides at least the following: The name of an 169 access protocol, and an address locating this service. The 170 service: URL may include url path information specific to the 171 type of service, as well as attribute information encoded 172 according to the URL grammar. The service: URL is used by 173 the Service Location Protocol to register and discover the 174 location of services. It may be used by other protocols and in 175 documents as well. 177 service type 179 A name identifying the semantics by which the remainder of 180 the service: URL is to be understood. It may denote either a 181 particular network protocol, or an abstract service associated 182 with a variety of protocols. If the service type denotes a 183 particular protocol, then the service type name SHOULD either 184 be assigned the name of a particular well known port [2] 185 by convention or or be the Assigned Numbers name for the 186 service [1]. 188 abstract service type 190 A service type name which is associated with a variety of 191 different protocols. An example is given in Section A. 192 Section 3 discusses various ways that abstract types can be 193 accommodated. 195 service registration 197 A service: URL and optionally a set of attributes comprise 198 a service registration. This registration is made by or on 199 behalf of a given service. The URL syntax and attributes must 200 conform to the service template for the registered service. 202 service template 204 A formal description of the service attributes and service 205 scheme associated with a particular service type. 207 1.2. Service Location Protocol 209 The Service Location Protocol [14] allows service: URLs to be 210 registered and discovered, though service: URLs may be also used in 211 other contexts. 213 Client applications discover service registrations by issuing queries 214 for services of a particular type, specifying the attributes of 215 the service: URLs to return. Clients retrieve the attributes of a 216 particular service by supplying its service: URL. Attributes for all 217 service registrations of a particular type can also be retrieved. 219 Services may register themselves, or registrations may be made on 220 their behalf. These registrations contain a service: URL, and 221 possibly attributes and digital signatures. 223 2. Related work 225 The "Finding Stuff" work by Ryan Moats, Martin Hamilton, and 226 Paul Leach uses service: URLs to provide access information about 227 arbitrary network protocols through DNS [10]. DNS SRV Resource 228 Records are a mechanism which provides a way to obtain a service by 229 type for a given domain [9], without specifying which instance of the 230 service type meet particular requirements. 232 3. Service URL Syntax and Semantics 234 This section describes the syntax and semantics of service: URLs. 236 3.1. Service URL Syntax 238 The syntax of the service: URL MUST conform to [5]. The only 239 exception is that the field has been omitted from the 240 production, since plain text transmission of passwords is 241 now discouraged. Note that the syntax for the field depends 242 upon the service type definition. The field is the service 243 access point, and describes how to access the service. In addition, 244 although both upper case and lower case characters are recognized in 245 the field for convenience, the name is case-folded 246 into lower case. Service types are therefore not distinguished on 247 the basis of case, so, for example, "http" and "HTTP" designate the 248 same service type. This is consistent with general URL practice, as 249 outlined in [6]. 251 The ABNF for a service: URL is: 253 service: URL = "service:" service-type ":" sap 254 service-type = abstract-type ":" url-scheme / concrete-type 255 abstract-type = type-name [ "." naming-auth ] 256 concrete-type = protocol [ "." naming-auth ] 257 type-name = resname 258 naming-auth = resname 259 url-scheme = resname 260 ; A recognized URL scheme name, standardized 261 ; either through common practice or through 262 ; approval of a standards body. 263 resname = alpha [ 1*(alpha / digit / "+" / "-") ] 264 sap = "//" site [ url-part ] 265 site = [ [ user "@" ] hostport ] 266 hostport = host [ ":" port ] 267 host = hostname / hostnumber 268 hostname = *( domainlabel "." ) toplabel 269 alphanum = alpha / digit 270 domainlabel = alphanum / alphanum *[alphanum / "-"] alphanum 271 toplabel = alpha / alpha *[ alphanum / "-" ] alphanum 272 hostnumber = ipv4-number / ipv6-number 273 ipv4-number = 1*3digit 3("." 1*3digit) 274 ipv6-number = 32hex 275 3digit = digit digit digit 276 port = 1*digit 277 ; A port number must be included if the 278 ; protocol field does not have an IANA 279 ; assigned port number. 280 user = *[ uchar / ";" / "+" / "&" / "=" ] 281 url-part = [ url-path ] [ attr-list ] 282 url-path = 1 * ( "/" *xchar ) 283 ; Each service type must define its 284 ; own syntax consistent 285 ; with [5]. 286 attr-list = 1 * ( ";" attr-asgn ) 287 attr-asgn = attr-id / attr-id "=" attr-value 288 safe = "$" / "-" / "_" / "." / "~" 289 extra = "!" / "*" / "'" / "(" / ")" / "," / "+" 290 uchar = unreserved / escaped 291 xchar = unreserved / reserved / escaped 292 escaped = "%" hex hex 293 hex "a" / "b" / "c" / "d" / "e" / digit 294 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" 295 unreserved = alpha / digit / safe / extra 297 Certain characters must be escaped before use. To escape any 298 character, precede the two digits indicating its ASCII value by '%'. 300 3.2. Service URL Semantics 302 The service scheme-specific information following the "service:" 303 URL scheme identifier provides information necessary to access the 304 service. As described in the previous subsection, the form of a 305 service: URL is as follows: 307 service: URL = "service:" service-type ":" sap 309 where has the following form: 311 //addr-spec/url-path;attr-list 313 The field includes the field. As 314 discussed in Section 1, the can be either a concrete 315 protocol name, or an abstract type name. 317 The field includes a site specification (the 318 field) in the format specified by [5]. The field 319 is typically either a domain name (DNS) or an IP network protocol 320 address for the service, and possibly a port number. Note that use 321 of DNS hostnames is preferred for ease of renumbering. The 322 field can be null if other information in the service URL or service 323 attributes is sufficient to use the service. 325 The field allows more information to be provided (by way of 326 and ) that can uniquely locate the service or 327 resource if the is not sufficient for that purpose. 329 An field appears at the end of the field, 330 but is never required to exist in any service location registration. 331 The field is composed of a list of semicolon (";") 332 separated attribute assignments of the form: 334 attr-id "=" attr-value 336 or for keyword attributes: 338 attr-id 340 Attributes are part of service: URLs when the attributes are required 341 to access a particular service. For instance, an ACAP [12] service 342 might require that the client authenticate with it through Kerberos. 343 Including an attribute in the service registration allows the ACAP 344 client to make use of the correct SASL [11] authentication mechanism. 345 The ACAP server's registration might look like: 347 service:acap://some.where.net;authentication=KERBEROSV4 349 Note that there can be other attributes of an ACAP server which are 350 not be appropriate to include in the URL. For instance, the list 351 of users who have access to the server is useful for selecting an 352 ACAP server, but is not required for a client to use the registered 353 service. 355 Attributes associated with the service: URL are not typically 356 included in the service: URL. They are stored and retrieved using 357 other mechanisms. The service: URL is uniquely identified with a 358 particular service agent or resource, and is used when registering or 359 requesting the attribute information. The Service Location Protocol 360 specifies how such information SHOULD be registered by network 361 services and obtained by client software. 363 3.3. Use of service: URLs 365 The service: URL is intended to allow arbitrary client/server and 366 peer to peer systems to make use of a standardized dynamic service 367 access point discovery mechanism. 369 It is intended that service: URLs be selected according to the 370 suitability of associated attributes. A client application can 371 obtain the URLs of several services of the same type and distinguish 372 the most preferable among them by means of their attributes. The 373 client uses the service: URL to communicate directly to a service. 375 Attributes are specified with a formal service template syntax 376 described in Section 4. If a service: URL registration includes 377 attributes, the registering agent SHOULD also keep track of the 378 attributes which characterize the service. 380 Registrations can be checked against the formal attribute 381 specification defined in the template by the client or agent 382 representing the client. Service registration are typically done 383 using the Service Location Protocol [14] (SLP). SLP provides a 384 mechanism for service: URLs to be obtained dynamically, according to 385 the service's attributes. 387 It is also possible to obtain service: URLs from documents and using 388 other protocols. In this case, the URL may not be accompanied by 389 the service attributes. The context in which the URL appears SHOULD 390 make it clear, if possible, when the service is appropriate to use. 391 For example, in a mail message, a service might be recommended for 392 use when the user is in a branch office. Or, an HTML document might 393 include a service: URL as a pointer to a service, describing in text 394 what the service does and who is authorized to use it. 396 3.4. Specifying the Service Type-Specific URL Syntax 398 When a service type is specified, the specification includes the 399 definition of the syntax for all URLs that are registered by services 400 of that particular type. For instance, the "lpr" service type may be 401 defined with service: URLs in the following form: 403 service:printer:lpr://
/ 405 The section of the URL after the address of the printer: 407 "/" 409 is specific to the lpr service type and corresponds to the 410 field of the general service: URL syntax. This part is 411 specified when the lpr service type is specified. 413 3.5. Accommodating Abstract Service Types 415 An abstract service type is a service type that can be implemented by 416 a variety of different service agents. 418 In order to register an service: URL for an abstract service type the 419 'abstract-type' grammar rule described in section 3.1 is used. This 420 will result in a URL which includes enough information to use the 421 service, namely, the protocol, address and path information. Unlike 422 'concrete' service: URLs, however, the service type is not enough 423 to determine the service access. Rather, an abstract service type 424 denotes a class of service types. The following subsection discusses 425 this point in more detail. 427 3.5.1. Advertising Abstract Service Types 429 Some services may make use of several protocols that are in common 430 use and are distinct services in their own right. In these cases an 431 abstract service type is appropriate. What is essential is that all 432 the required information for the service is clearly defined. 434 For example, suppose a network service is being developed for 435 dynamically loading device drivers. The client requires the 436 following three pieces of information before it can successfully load 437 and instantiate the driver: 439 1. The protocol used to load the driver code, for example, "ftp", 440 "http" or "tftp" 442 2. A pathname identifying where the driver code is located, for 443 example "/systemhost/drivers/diskdrivers.drv", 445 3. The name of the driver, for example, "scsi". 447 The temptation is to form the first two items into a URL and embed 448 that into a service: URL. As an example which should be avoided, 450 service:ftp:/x3.bean.org/drivers/diskdrivers.drv;driver=scsi 452 is a service: URL which seems to indicate where to obtain the driver. 454 Rather, an abstract service-type SHOULD be used. The service type is 455 not "ftp", as the example indicates. Rather, it is "device-drivers". 456 The service: URL that should be used, consistent with the rules in 457 section [6], is the following: 459 service:device-drivers:ftp://x3.bean.org/drivers/diskdrivers.drv; 460 driver=scsi;platform=sys3.2-rs3000 462 Other URLs for the same service using other protocols are also 463 supported, as in: 465 service:device-drivers:tftp://x2.bean.org/vol3/disk/drivers.drv; 466 driver=scsi;platform=sys3.2-rs3000 468 service:device-drivers:http://www.bean.org/drivers/drivpak.drv; 469 driver=scsi;platform=sys3.2-rs3000 471 Using SLP, a search for the service type "device-drivers" may return 472 all of the three URLs listed above. The client selects the most 473 appropriate access protocol for the desired resource. 475 The fundamental requirement is that the abstract service type MUST 476 be well specified. This requirement is imposed so that program code 477 or human users have enough information to access the service. In 478 every case, a well-specified abstract type will include either an 479 access protocol and a network address where the service is available, 480 or an embedded URL for a standardized URL scheme that describes 481 how to access the service. In the example above, there are three 482 further requirements: A URL path is included for access protocols 483 indicating the document to download, and two attributes are included 484 to characterize the driver. 486 4. Syntax and Semantics of Service Type Specifications 488 Service type specifications are documents in a formal syntax defining 489 properties important to service registration. These properties are: 491 1. General information on the service type specification itself, 493 2. The syntax of the service type-specific part of the service URL, 495 3. The definition of attributes associated with a service. 497 The service type specification document is the service type template. 499 The following subsections describe the syntax and semantics of 500 service type templates. 502 4.1. Syntax of Service Type Templates 504 Service template documents are encoded in a simple form. They may be 505 translated into any language or character set, but the template used 506 for standardization MUST be encoded in UTF8 [15] and be in English. 508 A template document begins with a block of text assigning values to 509 five document identification items. The five identification items 510 can appear in any order within the block, but conventionally the 511 "type" item, which assigns the service type name, occurs at the very 512 top of the document in order to provide context for the rest of 513 the the document. The attribute definition item occurs after the 514 document identification items. 516 All items end with a blank line. The reserved characters are ";", 517 "%", "=", ",", "#", LF, and CR. Reserved characters MUST be escaped. 518 The escape sequence is the same as described in [5]. 520 The service template is encoded in a UTF8 character set, but 521 submitted as a part of an internet-draft, which is encoded in ASCII 522 characters. All characters which are outside of the ASCII range MUST 523 be escaped using the % HEX HEX syntax. For example, the letter e 524 accent aigue would be represented as "%c3%a9". Unfortunately, this 525 will detract from the readability of the service template in the 526 internet draft. Hopefully some public domain tools will emerge for 527 translating escaped UTF8 characters into humanly readable ones. 529 Values in value lists are separated by commas. A value list is 530 terminated by a newline not preceded by a comma. If the newline is 531 preceded by a comma, the value list is interpreted to continue onto 532 the next line. 534 Attribute identifiers, attribute type names, and flags are all 535 case insensitive. For ease of presentation, upper and lower case 536 characters can be used to represent these in the template document. 537 Newlines are significant in the grammar. They delimit one item from 538 another, as well as separating parts of items internally. 540 String values are considered to be a sequence of non-whitespace 541 tokens potentially with embedded whitespace, separated from each 542 other by whitespace. Commas delimit lists of strings. String values 543 are trimmed so as to reduce any sequence of white space interior to a 544 string to a single white space. Preceding or trailing white space is 545 removed. For example: 547 " some value , another example " 549 is trimmed to 551 "some value" and "another example". 553 Note that there can be no ambiguity in string tokenization because 554 values in value lists are separated by a comma. String tokens are 555 not delimited by double quotes (") as is usually the case with 556 programming languages. 558 Attribute tags and values are useful for directory look-up. In this 559 case, decoding of character escapes and trimming white space MUST 560 be performed before string matching. In addition, string matching 561 SHOULD be case insensitive. 563 Templates obey the following ABNF [8] grammar: 565 template = tem-attrs attr-defs 566 tem-attrs = schemetype schemevers schemelang 567 schemetext schemeurl 568 schemetype = "type" "=" scheme termdef 569 schemevers = "version" "=" version-no termdef 570 schemelang = "language" "=" langtag termdef 571 schemetext = "description" "=" newline desc-text termdef 572 schemeurl = "url-syntax" "=" newline url-bnf termdef 573 url-bnf = *[ com-chars ] 574 ; An ABNF describing the production 575 ; in the service: URL grammar of Section 3.1. 576 scheme = service-type [ "." naming-auth ] 577 service-type = scheme-name 578 naming-auth = scheme-name 579 scheme-name = alpha [1*schemechar] [ "." 1*schemechar ] 580 schemechar = alpha / digit / "-" / "+" / 581 version-no = 1*digit "." 1*digit 582 langtag = 2*lower-alpha ;see [3] 583 desc-text = *[ com-chars ] 584 ; A block of free-form text for reading by 585 ; people describing the service in a short, 586 ; informative manner. 587 termdef = newline newline 588 attr-defs = *( attr-def / keydef ) 589 attr-def = id "=" attrtail 590 keydef = id "=" "keyword" newline [help-text] newline 591 attrtail = type flags newline [value-list] [help-text] 592 [value-list] newline 593 id = 1*attrchar 594 type = "string" / "integer" / "boolean" / "opaque" 595 flags = ["m"/"M"] ["l"/"L"] ["o"/"O"] ["x"/"X"] 596 value-list = value newline / value "," value-list / 597 value "," newline value-list 598 help-text = 1*( "#" help-line ) 599 ; A block of free-form text for reading by 600 ; people describing the attribute and 601 ; its values. 602 help-line = *[ com-chars ] newline 603 attrchar = schemechar / ":" / "_" / "$" / "~" / "@" / "." / 604 "|" / "<" / ">" / "*" / "&" 605 value = string / integer / boolean / opaque 606 string = safe-char *[safe-char / white-sp] safe-char 607 integer = [ "+" | "-" ] 1*digit 608 boolean = "true" / "false" 609 opaque = 1*digit ":" 4*radix64-char 610 ; The digits define the original length of 611 ; the opaque value. The restricted character 612 ; string is the radix-64 encoding of the 613 ; opaque value( [7], Sect. 6.8.) 614 ; Newlines are ignored in decoding radix-64 615 ; values. 616 com-chars = safe-char / white-sp / "," / ";"/ "%" 617 safe-char = attrchar / escaped / " " / "!" / '"' / "'" / 618 "|" / "(" / ")" / "+" / "-" / "." / ":" / 619 "=" / "?" / "[" / "]" / "{" / "/" / "{" / 620 "$" 621 ; All UTF8 printable characters are 622 ; included except ",", "%", ";", and "#". 623 escaped = "%" hex hex 624 hex = digit / "A" / "B" / "C" / "D" / "E" / 625 "a" / "b" / "c" / "d" / "e" 626 white-sp = space / tab 627 newline = CR / ( CR LF ) 629 4.2. Semantics of Service Type Templates 631 The service type template defines the service attributes and service: 632 URL syntax for a particular service type. The attribute definition 633 includes the attribute type, default values, allowed values and other 634 information. 636 4.2.1. Definition of a Service Template 638 There are six items included in the service template. The semantics 639 of each item is summarized below. 641 - type 643 The scheme name of the service scheme. The scheme name consists 644 of the service type name and an optional naming authority name, 645 separated from the service type name by a period. See 4.2.2 for 646 the conventions governing service type names. 648 - version 650 The version number of the service type specification. 652 - language 654 The language of the service type specification. 656 - description 658 A description of the service suitable for inclusion in text read 659 by people. 661 - url-syntax 663 The syntax of the service type-specific URL part of the service: 664 URL. 666 - attribute definitions 668 A collection of zero or more definitions for attributes 669 associated with the service in service registrations. 671 Each of the following subsections deals with one of these items. 673 4.2.2. Service Type 675 The service scheme consists of the service type name and an optional 676 naming authority name separated from the service type name by a 677 period. The service scheme is a string that is appended to the 678 'service:' URL scheme identifier, and is the value of the "type" 679 item in the template document. If the naming authority name is 680 absent it is assumed to be IANA. 682 4.2.3. Service Type Language 684 The service type language is a RFC 1766 Language Tag defining the 685 language of the template [3] and is the value of the "language" item. 687 4.2.4. Version Number 689 The version number of the service type template is the value of the 690 "version" item. A draft proposal starts at 0.0, and the minor number 691 increments once per revision. A standardized template starts at 1.0. 692 Additions of optional attributes add one to the minor number, and 693 additions of required attributes, changes of definition, or removal 694 of attributes add one to the major number. The intent is that an 695 old service template still accurately, if incompletely, defines the 696 attributes of a service registration if the template only differs 697 from the registration in its minor version. See Section 5 for more 698 detail on how to use the version attribute. 700 4.2.5. Description 702 The description is a block of text readable by people in the language 703 of the template and is the value of the "description" item. It 704 should be sufficient to identify the service to human readers and 705 provide a short, informative description of what the service does. 707 If the service type corresponds to a particular protocol, the 708 protocol specification must be cited here. The protocol need not be 709 a standardized protocol. The template might refer to a proprietary 710 specification, and refer the reader of the template to a contact 711 person for further information. 713 4.2.6. Syntax of the Service Type-specific URL Part 715 The syntax of the service type-specific part of the service: 716 URL is provided in the template document as the value of the 717 "url-syntax" item. The field of the service: URL is 718 designed to provide additional information to locate a service when 719 the field is not sufficient. The field 720 distinguishes URLs of a particular service type from those of another 721 service type. For instance, in the case of the lpr service type, the 722 must include the queue name [13], but other service types 723 may not require this information. 725 The syntax for the field MUST accompany the definition 726 of a new service type, unless the URL scheme has already been 727 standardized and is not a service: URL. The syntax is included in the 728 template document as an ABNF [8] following the rules for URL syntax 729 described in [5]. There is no requirement for a service scheme to 730 support a . The field can be very simple, 731 or even omitted. If the URL scheme has already been standardized, 732 the "url-syntax" item SHOULD include a reference to the appropriate 733 standardization documents. Abstract service types may defer this 734 field to the template documents describing their concrete instances. 736 4.2.7. Attribute Definition 738 The bulk of the template is typically devoted to defining service 739 type-specific attributes. An attribute definition precisely 740 specifies the attribute's type, other restrictions on the attribute 741 (whether it is multi-valued, optional, etc), some text readable by 742 people describing the attribute, and lists of default and allowed 743 values. The only required information is the attribute's type, the 744 rest are optional. Registration, deregistration and the use of 745 attributes in queries can be accomplished using the Service Location 746 Protocol [14] or other means, and discussion of this is beyond the 747 scope of the document. 749 Attributes are used to convey information about a given service for 750 purposes of differentiating different services of the same type. 751 They convey information to be used in the selection of a particular 752 service to establish communicate with, either through a program 753 offering a human interface or programmatically. Attributes can be 754 encoded in different character sets and in different languages. The 755 procedure for doing this is described in Section 7. 757 An attribute definition begins with the specification of the 758 attribute's identifier and ends with a single empty line. Attributes 759 definitions have five components (in order of appearance in a 760 definition): 762 1. An attribute identifier which acts as the name of the attribute, 764 2. Attribute descriptors (type and flags), 766 3. An optional list of values which are assigned to the attribute by 767 default, 769 4. An optional block of text readable by people providing a short, 770 informative description of the attribute, 772 5. An optional list of allowed values which restrict the value or 773 values the attribute can take on. 775 4.2.7.1. The Attribute Identifier 777 An attribute definition starts with the specification of the 778 attribute's identifier. The attribute's identifier functions as the 779 name of the attribute. Note that the characters used to compose an 780 attribute identifier are restricted to those characters considered 781 unrestricted for inclusion in a URL according to [5]. The reason 782 is that services can display prominent attributes in their service: 783 URL registrations. Each attribute identifier must be unique in the 784 template. Since identifiers are case folded, upper case and lower 785 case characters are the same. 787 4.2.7.2. The Attribute Type 789 Attributes can have one of five different types: string, integer, 790 boolean, opaque, or keyword. The attribute's type specification is 791 separated from the attribute's identifier by an equal sign ("=") and 792 follows the equal sign on the same line. The string, signed integer, 793 and boolean types have the standard programming language or database 794 semantics. Integers are restricted to those signed values that can 795 be represented in 32 bits. The character set used to represent 796 strings is not specified at the time the template is defined, but 797 rather is determined by the service registration. Booleans have the 798 standard syntax. Opaques are radix64 numbers [7] that can be used 799 to represent any other kind of data. Keywords are attributes that 800 have no characteristics other than their existence (and possibly the 801 descriptive text in their definition). 803 Keyword and boolean attributes impose restrictions on the following 804 parts of the attribute definition. Keyword attribute definitions 805 MUST have no flag information following the type definition, nor any 806 default or allowed values list. Boolean attributes are single value 807 only, i.e., multi-valued boolean attributes are not allowed. 809 4.2.7.3. Attribute Flags 811 Flags determine other characteristics of an attribute. With the 812 exception of keyword attributes, which may not have any flags, 813 flags follow the attribute type on the same line as the attribute 814 identifier, and are separated from each other by whitespace. Flags 815 may appear in any order after the attribute type. Other information 816 must not follow the flags, and only one flag identifier of a 817 particular flag type is allowed per attribute definition. 819 The semantics of the flags are as follows: 821 - o or O 823 Indicates that the attribute is optional. If this flag is 824 missing, the attribute is required in every service registration. 826 - m or M 828 Indicates that the attribute can take on multiple values. If 829 this flag is present, every value in a multi-valued attribute 830 has the same type as the type specified in the type part of the 831 attribute definition. Boolean attributes must not include this 832 flag. 834 - l or L 836 Indicates that attribute is literal, i.e. is not meant to be 837 translated into other languages. If this flag is present, the 838 attribute is not considered to be readable by people and should 839 not be translated when the template is translated. See Section 7 840 for more information about translation. 842 - x or X 844 Indicates that clients SHOULD include the indicate attribute in 845 requests for services. Neglecting to include this attribute will 846 not sufficiently differentiate the service. If services are 847 obtained without selecting this attribute they will quite likely 848 be useless to the client. 850 The values for multivalued attributes are an unordered set. 851 Deletions of individual values from a multivalued attribute are not 852 supported, and deletion of the attribute causes the entire set of 853 values to be removed. 855 4.2.7.4. Default Value or List 857 If the attribute definition includes a default value or, in the 858 case of multivalued attributes, a default values list, it begins 859 on the second line of the attribute definition and continues 860 over the following lines until a line ends without a comma. As a 861 consequence, newlines cannot be embedded in values unless escaped. 862 See Section 3.1. 864 Particular attribute types and definitions restrict the default 865 values list. Keyword attributes must not have a list of defaults. 866 If an optional attribute's definition has an allowed values list, 867 then a default value or list is not optional but required. The 868 motivation for this is that defining an attribute with an allowed 869 values list is meant to restrict the values the attribute can take 870 on, and requiring a default value or list assures that the default 871 value is a member of the given set of allowed values. 873 The default value or list indicates what values the attribute is 874 given if no values are assigned to the attribute when a service 875 is registered. If an optional attribute's definition includes no 876 default value or list, the following defaults are assigned: 878 1. String values are assigned the empty string, 880 2. Integer values are assigned zero, 882 3. Boolean values are assigned false, 884 4. Opaque values are assigned a byte array containing no values, 886 5. Multi-valued attributes are initialized with a single value. 888 For purposes of translating nonliteral attributes, the default values 889 list is taken to be an ordered set, and translations MUST maintain 890 that order. 892 4.2.7.5. Descriptive Text 894 Immediately after the default values list, if any, a block of 895 descriptive text SHOULD be included in the attribute definition. 896 This text is meant to be readable by people, and should include 897 a short, informative description of the attribute. It may also 898 provide additional information, such as a description of the allowed 899 values. This text is primarily designed for display by interactive 900 browsing tools. The descriptive text is set off from the surrounding 901 definition by a crosshatch character ("#") at the beginning of 902 the line. The text should not, however, be treated as a comment 903 by parsing and other tools, since it is an integral part of the 904 attribute definition. Within the block of descriptive text, the text 905 is transferred verbatim, including indentation and line breaks, so 906 any formatting is preserved. 908 4.2.7.6. Allowed Values List 910 Finally, the attribute definition concludes with an optional 911 allowed values list. The allowed values list, if any, follows the 912 descriptive text, or, if the descriptive text is absent, the initial 913 values list. The syntax of the allowed values list is identical to 914 that of the initial values list. The allowed values list is also 915 terminated by a line that does not end in a comma. If the allowed 916 values list is present, assignment to attributes is restricted to 917 members of the list. 919 As with the default values list, the allowed values list is also 920 considered to be an ordered set for purposes of translation. 922 4.2.7.7. Conclusion of An Attribute Definition 924 An attribute definition concludes with a single empty line. 926 5. A Process For Standardizing New Service Types 928 New service types can be suggested simply by providing a service type 929 template and a short description about how to use the service. The 930 template MUST have its "version" template attribute set to 0.0. 932 The minor version number increments once with each change until it 933 achieves 1.0. There is no guarantee any version of the service 934 template is backward compatible before it reaches 1.0. 936 Once a service template has reached 1.0, the definition is "frozen" 937 for that version. New templates must be defined, of course, to 938 refine that definition, but the following rules must be followed: 940 A MINOR revision number signifies the introduction of a compatible 941 change. A MAJOR revision number signifies the introduction of an 942 incompatible change. This is formalized by the following rules: 944 - Any new optional attribute defined for the template increases 945 the minor version number by one. All other attributes for the 946 version must continue to be supported as before. A client which 947 supports 1.x can still use later versions of 1.y (where x "." "." 1002 Each of these fields are defined in Section 3. They correspond 1003 to the values of the template fields "type", "version" and 1004 "lang". The files for the example templates in this document 1005 are called "acap.0.0.en", "network-management.0.0.en" and 1006 "network-management:snmp.0.0.en". See Section A. 1008 No service type template will be accepted for inclusion in the 1009 service template registry unless the internet draft submitted 1010 includes a security considerations section and contact information 1011 for the template document author. 1013 The IANA will maintain a registry containing both the service type 1014 templates, and the template description document containing the 1015 service type template, including all previous versions. The IANA 1016 will receive notice by email from the reviewers, which will contain a 1017 reference to the Internet Draft that contains the service template. 1018 This Internet Draft will be edited to remove the Internet Draft 1019 headers and replace them with a simple header stating "This document 1020 contains a Service Type Template." 1022 Neither the reviewer nor the IANA will take any position on claims of 1023 copyright or trademark issues with regard to templates.' 1025 7. Internationalization Considerations 1027 The service: URL must be encoded using the rules set forth in [5]. 1028 The character set encoding is limited to specific ranges within the 1029 US-ASCII character set [4]. 1031 The template is encoded in UTF8 characters. 1033 7.1. Language Identification and Translation 1035 The language used in attribute strings should be identified using the 1036 "language" template item as defined by [3]. 1038 A program can translate a service registration from one language to 1039 another provided it has both the template of the language for the 1040 registration and the template of the desired target language. All 1041 standardized attributes are in the same order in both templates. 1042 All non-arbitrary strings, including the descriptive help text, is 1043 directly translatable from one language to another. Non-literal 1044 attribute definitions, attribute identifiers, attribute type names, 1045 attribute flags, and the boolean constants "true" and "false" are 1046 never translated. Translation of attribute identifiers is prohibited 1047 because, as with domain names, they can potentially be part of a 1048 service: URL and therefore their character set is restricted. In 1049 addition, as with variable identifiers in programming languages, they 1050 could become embedded into program code. 1052 All strings used in attribute values are assumed translatable unless 1053 explicitly defined as being literal, so that best effort translation 1054 (see below) does not modify strings which are meant to be interpreted 1055 by a program, not a person. 1057 There are two ways to go about translation: standardization and best 1058 effort. 1060 When the service type is standardized, more than one document can 1061 be submitted for review. One service type description is approved 1062 as a master, so that when a service type template is updated in one 1063 language, all the translations (at least eventually) reflect the same 1064 semantics. 1066 If no document exists describing the standard translation of the 1067 service type, a 'best effort' translation for strings should be done. 1069 8. Security Considerations 1071 Service type templates provide information that is used to interpret 1072 information obtained by the Service Location Protocol. If these 1073 templates are modified or false templates are distributed, services 1074 may not correctly register themselves, or clients might not be able 1075 to interpret service information. 1077 The service: URLs themselves specify the service access point and 1078 protocol for a particular service type. These service: URLs could 1079 be distributed and indicate the location of a service other than 1080 that normally want to used. The Service Location Protocol [14] 1081 distributes service: URLs and has an authentication mechanism that 1082 allows service: URLs of registered services to be signed and for the 1083 signatures to be verified by clients. 1085 Each Service Template will include a security considerations section 1086 which will describe security issues with using the service scheme for 1087 the specific Service Type. 1089 A. Service Template Examples 1091 The text in the template example sections is to be taken as being a 1092 single file. 1094 The ACAP example shows how to use service templates for an 1095 application that has very few attributes. Clients request the ACAP 1096 server where their user data is located by including their user name 1097 as the value of the user attribute. 1099 The Network-Management example shows how abstract service types are 1100 defined and how a corresponding concrete instance is defined. A 1101 system might support any of several Network-Management services. 1102 Here we give only one concrete instance of the abstract type. It is 1103 not necessary to register concrete templates for an abstract service 1104 type if the abstract service type template is completely clear as to 1105 what possible values can be used as a concrete type, and what their 1106 interpretation is. 1108 A.1. ACAP 1110 -------------------------template begins here----------------------- 1111 type=ACAP 1113 version=0.0 1115 lang=en 1117 description= 1118 The ACAP service URL provides the location of an ACAP service. 1120 url-syntax= 1121 url-path= ; There is no URL path defined for an ACAP URL. 1123 users= string M L O 1124 # The list of all users which the ACAP server supports. 1126 groups= string M L O 1127 # The list of all groups which the ACAP server supports. 1128 --------------------------template ends here------------------------ 1130 The Internet Draft describing the ACAP scheme template must indicate 1131 contact information and security considerations, e.g., 1133 contact="Erik Guttman" 1135 security considerations= 1136 If the USER and GROUPS attributes are included a 1137 possibility exists that the list of identities for users or groups 1138 can be discovered. This information would otherwise be difficult 1139 to discover. 1141 A.2. Abstract Service Template Example: Network-Management 1143 The Internet Draft for the service type template contains the 1144 following text: 1146 -------------------------template begins here----------------------- 1147 type=Network-Management 1149 version=0.0 1151 lang=en 1153 description= 1154 This is an abstract service type. The purpose of the network- 1155 management service type is to organize into a single category 1156 information crucial to properly managing networked hosts. This 1157 will allow all network-management services of a host, as well 1158 as basic host configuration to be obtained by a single query 1159 using SLP. 1161 url-syntax= 1162 url-path= ; Depends on the concrete service type. 1163 ; See these templates. 1164 --------------------------template ends here------------------------ 1166 In addition, the following format might be used for the needed 1167 contact and security considerations information. 1168 .......... 1170 contact="Erik Guttman" 1172 security considerations= 1173 See the security considerations of the concrete service types. 1175 A.3. Concrete Service Template Example: Network-Management:SNMP 1177 -------------------------template begins here----------------------- 1178 type=service:network-management:snmp 1179 version=0.0 1181 lang=en 1183 description= 1184 The 'service:network-management:SNMP:' URL provides information 1185 about the SNMP manageability of a given host. Namely, if this 1186 URL exists for a host (denoted by the in the URL,) 1187 the host supports SNMP. The path contains an enumeration of 1188 the MIB groups that are supported by the host. The OID "1.3.6.1." 1189 is assumed as a prefix to each of the OID terms below. 1191 url-syntax= 1192 url-path = ( [port-list] [comm-string] [oid-list]) 1193 ; None of the attributes listed in the URL path 1194 ; are required. They MAY be included. 1195 port-list = ";ports=" port-list 1196 ports = port / port "," ports 1197 ; See the Service URL production rule. 1198 ; This field is defined as an attribute, below. 1199 comm-string = ";read-community-string=" 1*uchar 1200 ; See the Service URL production rule. 1201 ; This field is defined as an attribute, below. 1202 oid-list = ";oids=" oids 1203 ; This field is defined as an attribute, below. 1204 oids = oid / oid "," oids 1205 oid = DIGIT [ "." (DIGIT ".") DIGIT] 1207 ports=integer M L 1208 161 1209 # This attribute must be included. It lists all ports on which 1210 # SNMP Agents are listening. 1212 read-community-string=string L O 1213 # The read community string may be included as an attribute of 1214 # a service:network-managment:snmp: URL. This is useful in 1215 # cases where the community string is PUBLIC and ease of access 1216 # to the SNMP Agent is desired. See the 'security considerations.' 1218 oid=string M L O 1219 # This attribute identifies a list of 'top level' MIB groups. 1220 # This is entirely optional, as such values can be obtained 1221 # directly using SNMP. The value of including this information 1222 # in a service:network-managment:snmp: URL is that it will save 1223 # the Manager time; the MIB information can be obtained along 1224 # with the URL without requiring additional sequential requests 1225 # being sent to the managed system. 1226 --------------------------template ends here------------------------ 1227 ......... 1229 contact="Erik Guttman" 1231 security considerations= 1232 The read-community-string MUST only be included if the value 1233 of this string is considered to be public. If this attribute 1234 is included, absolutely anyone may access the SNMP Agent and 1235 get information from it. This may be desirable in some cases. 1236 If this string is considered confidential information, the 1237 read-community-string MUST NOT be included in the URL path 1238 nor in service registrations of the URL made through SLP or 1239 other protocols. 1241 A.4. service: URLs and SLP 1243 A user with an ACAP enabled email client application should not 1244 be bothered with knowing the address of their ACAP server. The 1245 mail client program can use SLP to obtain the ACAP service: URL 1246 automatically, say 'service:acap://server1.nosuch.org', by issuing 1247 a Service Request. In the event that this ACAP server failed, the 1248 Email client can issue the same service request again to find the 1249 backup ACAP server, say 'service:acap://server2.nosuch.org'. In both 1250 cases, the service: URL conforms to the ACAP service template as do 1251 the associated attributes (user and group.) 1253 An SNMP based network Manager can use SLP to obtain 1254 service:network-management:SNMP URLs. This allows the network 1255 Manager to proceed to manage the hosts identified by these URLs 1256 without having to scan networks one address at a time, etc. SLP 1257 provides the capability to send multicast or directed broadcasts to 1258 obtain this information from every managed host. 1260 B. Full Copyright Statement 1262 Copyright (C) The Internet Society (1997). All Rights Reserved. 1264 This document and translations of it may be copied and furnished to 1265 others, and derivative works that comment on or otherwise explain it 1266 or assist in its implmentation may be prepared, copied, published 1267 and distributed, in whole or in part, without restriction of any 1268 kind, provided that the above copyright notice and this paragraph 1269 are included on all such copies and derivative works. However, 1270 this document itself may not be modified in any way, such as by 1271 removing the copyright notice or references to the Internet Society 1272 or other Internet organizations, except as needed for the purpose 1273 of developing Internet standards in which case the procedures 1274 for copyrights defined in the Internet Standards process must be 1275 followed, or as required to translate it into languages other than 1276 English. 1278 The limited permissions granted above are perpetual and will not be 1279 revoked by the Internet Society or its successors or assigns. 1281 This document and the information contained herein is provided on an 1282 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1283 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1284 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1285 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1286 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1288 References 1290 [1] Protocol and service names, October 1994. 1291 ftp://ftp.isi.edu/in-notes/iana/assignments/service-names. 1293 [2] Port numbers, July 1997. 1294 ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers. 1296 [3] H. Alvestrand. Tags for the Identification of Languages. RFC 1297 1766, March 1995. 1299 [4] ANSI. Coded Character Set -- 7-bit American Standard code for 1300 Information Interchange. X3.4-1986, 1986. 1302 [5] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource 1303 Locators (URL): Generic Syntax and Semantics. RFC1738 as 1304 amended by RFC1808 and updated by draft-fielding-url-syntax-05.txt, 1305 May 1997. (work in progress). 1307 [6] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource 1308 Locators (URL). RFC 1738, December 1994. 1310 [7] N. Borenstein and N. Freed. Multipurpose Internet Mail 1311 Extensions (MIME) Part One: Format of Internet Message Bodies. 1312 RFC 2045, November 1996. 1314 [8] D. Crocker and P. Overell. Augmented BNF for Syntax 1315 Specifications: ABNF. draft-ietf-drums-abnf-04.txt, September 1316 1997. (work in progress). 1318 [9] A. Gulbrandsen and P. Vixie. A DNS RR for specifying the 1319 location of services (DNS SRV). RFC 2052, October 1996. 1321 [10] R. Moats and M. Hamilton. Finding Stuff (How to discover 1322 services). draft-ietf-svrloc-discovery-05.txt, October 1997. 1323 (work in progress). 1325 [11] J. Myers. Simple Authentication and Security Layer (SASL). 1326 draft-myers-auth-sasl-11.txt, May 1997. (work in progress). 1328 [12] J. G. Myers. ACAP -- Application Configuration Access Prototol. 1329 draft-ietf-acap-spec-04.txt, June 1997. (work in progress). 1331 [13] Pete St. Pierre. Definition of lpr: URLs for use with Service 1332 Location. draft-ietf-svrloc-lpr-scheme-00.txt, July 1997. 1333 (work in progress). 1335 [14] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 1336 Location Protocol. RFC 2165, July 1997. 1338 [15] F. Yergeau. UTF-8, a transformation format of unicode and ISO 1339 10646. RFC 2044, October 1996. 1341 Authors' Addresses 1343 Questions about this memo can be directed to: 1345 Erik Guttman Charles E. Perkins James Kempf 1346 Sun Microsystems Sun Microsystems Sun Microsystems 1347 Bahnstr. 2 901 San Antonio Rd. 901 San Antonio Rd. 1348 74915 Waibstadt Palo Alto, CA, 94303 Palo Alto, CA, 94303 1349 Germany USA USA 1350 +49 7263 911484 1 650 786 6464 1 650 786 5890 1351 1 650 786 6445 (fax) 1 650 786 6445 (fax) 1352 erik.guttman@sun.com charles.perkins@sun.com james.kempf@sun.com