idnits 2.17.1 draft-ietf-svrloc-service-scheme-10.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 51: '... They SHOULD be used by administrati...' RFC 2119 keyword, line 181: '...en the service type name SHOULD either...' RFC 2119 keyword, line 226: '... The syntax of the service: URL MUST conform to [6]. The only...' RFC 2119 keyword, line 403: '...egistering agent SHOULD also keep trac...' RFC 2119 keyword, line 480: '...act service-type SHOULD be used. The ...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1386 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 1317, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1336, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1343, 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 2234 (ref. '9') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2052 (ref. '10') (Obsoleted by RFC 2782) ** Obsolete normative reference: RFC 2222 (ref. '11') (Obsoleted by RFC 4422, RFC 4752) == Outdated reference: A later version (-06) exists of draft-ietf-svrloc-printer-scheme-02 -- Possible downref: Normative reference to a draft: ref. '13' ** Obsolete normative reference: RFC 2044 (ref. '15') (Obsoleted by RFC 2279) -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' Summary: 16 errors (**), 0 flaws (~~), 7 warnings (==), 12 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 21 June 1998 Sun Microsystems 6 Service Templates and service: Schemes 7 draft-ietf-svrloc-service-scheme-10.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 view the entire list of current Internet-Drafts, please check 28 the "1id-abstracts.txt" listing contained in the Internet-Drafts 29 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 30 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 31 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 32 (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 38 be used by the Service Location Protocol in order to distribute 39 service access information. These schemes provide an extensible 40 framework for client-based network software to obtain configuration 41 information required to make use of network services. When 42 registering a service: URL, the URL is accompanied by a set of 43 well-defined attributes which define the service. These attributes 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 1 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.2. Service Location Protocol . . . . . . . . . . . . . . . . 3 65 2. Service URL Syntax and Semantics 3 66 2.1. Service URL Syntax . . . . . . . . . . . . . . . . . . . 3 67 2.2. Service URL Semantics . . . . . . . . . . . . . . . . . . 5 68 2.3. Use of service: URLs . . . . . . . . . . . . . . . . . . 7 69 2.4. Specifying the Service Type-Specific URL Syntax . . . . . 7 70 2.5. Accommodating Abstract Service Types . . . . . . . . . . 8 71 2.5.1. Advertising Abstract Service Types . . . . . . . 8 73 3. Syntax and Semantics of Service Type Specifications 9 74 3.1. Syntax of Service Type Templates . . . . . . . . . . . . 10 75 3.2. Semantics of Service Type Templates . . . . . . . . . . . 12 76 3.2.1. Definition of a Service Template . . . . . . . . 12 77 3.2.2. Service Type . . . . . . . . . . . . . . . . . . 13 78 3.2.3. Service Type Language . . . . . . . . . . . . . . 13 79 3.2.4. Version Number . . . . . . . . . . . . . . . . . 14 80 3.2.5. Description . . . . . . . . . . . . . . . . . . . 14 81 3.2.6. Syntax of the Service Type-specific URL Part . . 14 82 3.2.7. Attribute Definition . . . . . . . . . . . . . . 15 84 4. A Process For Standardizing New Service Types 19 86 5. IANA Considerations 20 88 6. Internationalization Considerations 21 89 6.1. Language Identification and Translation . . . . . . . . . 21 91 7. Security Considerations 22 93 A. Service Template Examples 22 94 A.1. FOO . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 A.2. Abstract Service Type: Net-Transducer . . . . . . . . . 23 96 A.3. Concrete Service Type: Net-Transducer:Thermometer . . . 24 97 A.4. service: URLs and SLP . . . . . . . . . . . . . . . . . . 25 99 B. Full Copyright Statement 27 100 C. Acknowledgments 27 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 [14] 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 [13]. 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] by 183 convention or be the Assigned Numbers name for the service [1]. 185 abstract service type 187 A service type name which is associated with a variety of 188 different protocols. An example is given in Section A. 189 Section 2 discusses various ways that abstract types can be 190 accommodated. 192 service registration 194 A service: URL and optionally a set of attributes comprise 195 a service registration. This registration is made by or on 196 behalf of a given service. The URL syntax and attributes must 197 conform to the service template for the registered service. 199 service template 201 A formal description of the service attributes and service 202 scheme associated with a particular service type. 204 1.2. Service Location Protocol 206 The Service Location Protocol [14] allows service: URLs to be 207 registered and discovered, though service: URLs may be also used in 208 other contexts. 210 Client applications discover service registrations by issuing queries 211 for services of a particular type, specifying the attributes of 212 the service: URLs to return. Clients retrieve the attributes of a 213 particular service by supplying its service: URL. Attributes for all 214 service registrations of a particular type can also be retrieved. 216 Services may register themselves, or registrations may be made on 217 their behalf. These registrations contain a service: URL, and 218 possibly attributes and digital signatures. 220 2. Service URL Syntax and Semantics 222 This section describes the syntax and semantics of service: URLs. 224 2.1. Service URL Syntax 226 The syntax of the service: URL MUST conform to [6]. The only 227 exception is that the field has been omitted from the 228 production, since plain text transmission of passwords is 229 now discouraged. Note that the syntax for the field depends 230 upon the service type definition. The field is the service 231 access point, and describes how to access the service. In addition, 232 although both upper case and lower case characters are recognized in 233 the field for convenience, the name is case-folded 234 into lower case. Service types are therefore not distinguished on 235 the basis of case, so, for example, "http" and "HTTP" designate the 236 same service type. This is consistent with general URL practice, as 237 outlined in [7]. 239 The ABNF for a service: URL is: 241 service: URL = "service:" service-type ":" sap 242 service-type = abstract-type ":" url-scheme / concrete-type 243 abstract-type = type-name [ "." naming-auth ] 244 concrete-type = protocol [ "." naming-auth ] 245 type-name = resname 246 naming-auth = resname 247 url-scheme = resname 248 ; A recognized URL scheme name, standardized 249 ; either through common practice or through 250 ; approval of a standards body. 251 resname = alpha [ 1*(alpha / digit / "+" / "-") ] 252 sap = site [url-part] 253 site = ipsite / atsite / ipxsite 254 ipsite = "//" [ [ user "@" ] hostport ] 255 hostport = host [ ":" port ] 256 host = hostname / hostnumber 257 hostname = *( domainlabel "." ) toplabel 258 alphanum = alpha / digit 259 domainlabel = alphanum / alphanum *[alphanum / "-"] alphanum 260 toplabel = alpha / alpha *[ alphanum / "-" ] alphanum 261 hostnumber = ipv4-number / ipv6-number 262 ipv4-number = 1*3digit 3("." 1*3digit) 263 ipv6-number = 32hex 264 3digit = digit digit digit 265 port = 1*digit 266 ; A port number must be included if the 267 ; protocol field does not have an IANA 268 ; assigned port number. 269 user = *[ uchar / ";" / "+" / "&" / "=" ] 270 ipxsite = "/ipx/" ipx-net ":" ipx-node ":" ipx-socket 271 ipx-net = 8 HEXDIGIT 272 ipx-node = 12 HEXDIGIT 273 ipx-socket = 4 HEXDIGIT 274 atsite = "/at/" at-object ":" at-type "" at-zone 275 at-object = 1*31apple-char 276 at-type = 1*31apple-char 277 at-zone = 1*31apple-char 278 apple-char = alpha / digit / safe / escaped 279 = ; AppleAscii [17] values that are not 280 = ; from the restricted range must be escaped. 281 = ; NOTE: The escaped values do NOT correspond 282 = ; to UTF8 values here: They are AppleAscii 283 = ; bytes. 284 url-part = [ url-path ] [ attr-list ] 285 url-path = 1 * ( "/" *xchar ) 286 ; Each service type must define its 287 ; own syntax consistent 288 ; with [6]. 289 attr-list = 1 * ( ";" attr-asgn ) 290 attr-asgn = attr-id / attr-id "=" attr-value 291 safe = "$" / "-" / "_" / "." / "~" 292 extra = "!" / "*" / "'" / "(" / ")" / "," / "+" 293 uchar = unreserved / escaped 294 xchar = unreserved / reserved / escaped 295 escaped = "%" hex hex 296 hex "a" / "b" / "c" / "d" / "e" / digit 297 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" 298 unreserved = alpha / digit / safe / extra 300 IPX addresses [19] are composed of a network, node and socket number. 301 The IPX network number is a four-byte number, in network order and 302 expressed in hexadecimal, that signifies an IPX subnet. The node 303 element represents a network interface card. It is a six-byte 304 number, expressed in hexadecimal, that is usually the same as the 305 node ID of the interface card. The socket element represents a 306 specific service access point, given an IPX network and node. IPX 307 sockets are analogous to TCP/IP ports, and are not to be confused 308 with Berkely sockets. 310 AppleTalk addresses [18] are composed of an object, type and zone. 311 The object is a human readable string. The type is an identifier, 312 not intentended for human readability. The zone refers to the 313 AppleTalk Zone name, which is also human readable. The characters 314 composing these names are drawn from the AppleAscii character 315 set [17]. Thus, they do not equate to escaped ASCII or UTF8 316 characters. The characters "=" and "*" are reserved and may not be 317 included in the names even in binary form. 319 In cases besides the AppleTalk grammar, some characters must be 320 escaped before use. To escape any character, precede the two digits 321 indicating its ASCII value by '%'. 323 2.2. Service URL Semantics 325 The service scheme-specific information following the "service:" 326 URL scheme identifier provides information necessary to access the 327 service. As described in the previous subsection, the form of a 328 service: URL is as follows: 330 service: URL = "service:" service-type ":" sap 332 where has the following form: 334 /addr-family/addr-spec/url-path;attr-list 336 The field includes the field. As 337 discussed in Section 1, the can be either a concrete 338 protocol name, or an abstract type name. 340 The field includes a site specification (the 341 field) in the format specified by [6]. The field 342 is typically either a domain name (DNS) or an IP network protocol 343 address for the service, and possibly a port number. Note that use 344 of DNS hostnames is preferred for ease of renumbering. The 345 field can be null if other information in the service URL or service 346 attributes is sufficient to use the service. 348 The field allows more information to be provided (by way of 349 and ) that can uniquely locate the service 350 or resource if the is not sufficient for that purpose. 351 For IP addresses, is empty, the field begins 352 with "//". Other address families supported are IPX [19] and 353 AppleTalk [?]. 355 An field appears at the end of the field, 356 but is never required to exist in any service location registration. 357 The field is composed of a list of semicolon (";") 358 separated attribute assignments of the form: 360 attr-id "=" attr-value 362 or for keyword attributes: 364 attr-id 366 Attributes are part of service: URLs when the attributes are required 367 to access a particular service. For instance, an ACAP [12] service 368 might require that the client authenticate with it through Kerberos. 369 Including an attribute in the service registration allows the ACAP 370 client to make use of the correct SASL [11] authentication mechanism. 371 The ACAP server's registration might look like: 373 service:acap://some.where.net;authentication=KERBEROSV4 375 Note that there can be other attributes of an ACAP server which 376 are not appropriate to include in the URL. For instance, the list 377 of users who have access to the server is useful for selecting an 378 ACAP server, but is not required for a client to use the registered 379 service. 381 Attributes associated with the service: URL are not typically 382 included in the service: URL. They are stored and retrieved using 383 other mechanisms. The service: URL is uniquely identified with a 384 particular service agent or resource, and is used when registering or 385 requesting the attribute information. The Service Location Protocol 386 specifies how such information is registered by network services and 387 obtained by client software. 389 2.3. Use of service: URLs 391 The service: URL is intended to allow arbitrary client/server and 392 peer to peer systems to make use of a standardized dynamic service 393 access point discovery mechanism. 395 It is intended that service: URLs be selected according to the 396 suitability of associated attributes. A client application can 397 obtain the URLs of several services of the same type and distinguish 398 the most preferable among them by means of their attributes. The 399 client uses the service: URL to communicate directly to a service. 401 Attributes are specified with a formal service template syntax 402 described in Section 3. If a service: URL registration includes 403 attributes, the registering agent SHOULD also keep track of the 404 attributes which characterize the service. 406 Registrations can be checked against the formal attribute 407 specification defined in the template by the client or agent 408 representing the client. Service registration are typically done 409 using the Service Location Protocol [14] (SLP). SLP provides a 410 mechanism for service: URLs to be obtained dynamically, according to 411 the service's attributes. 413 It is also possible to obtain service: URLs from documents and using 414 other protocols. In this case, the URL may not be accompanied by 415 the service attributes. The context in which the URL appears should 416 make it clear, if possible, when the service is appropriate to use. 417 For example, in a mail message, a service might be recommended for 418 use when the user is in a branch office. Or, an HTML document might 419 include a service: URL as a pointer to a service, describing in text 420 what the service does and who is authorized to use it. 422 2.4. Specifying the Service Type-Specific URL Syntax 424 When a service type is specified, the specification includes the 425 definition of the syntax for all URLs that are registered by services 426 of that particular type. For instance, the "lpr" service type may be 427 defined with service: URLs in the following form: 429 service:printer:lpr://
/ 431 The section of the URL after the address of the printer: 433 "/" 435 is specific to the lpr service type and corresponds to the 436 field of the general service: URL syntax. This part is 437 specified when the lpr service type is specified. 439 2.5. Accommodating Abstract Service Types 441 An abstract service type is a service type that can be implemented by 442 a variety of different service agents. 444 In order to register an service: URL for an abstract service type the 445 'abstract-type' grammar rule described in section 3.1 is used. This 446 will result in a URL which includes enough information to use the 447 service, namely, the protocol, address and path information. Unlike 448 'concrete' service: URLs, however, the service type is not enough 449 to determine the service access. Rather, an abstract service type 450 denotes a class of service types. The following subsection discusses 451 this point in more detail. 453 2.5.1. Advertising Abstract Service Types 455 Some services may make use of several protocols that are in common 456 use and are distinct services in their own right. In these cases an 457 abstract service type is appropriate. What is essential is that all 458 the required information for the service is clearly defined. 460 For example, suppose a network service is being developed for 461 dynamically loading device drivers. The client requires the 462 following three pieces of information before it can successfully load 463 and instantiate the driver: 465 1. The protocol used to load the driver code, for example, "ftp", 466 "http" or "tftp" 468 2. A pathname identifying where the driver code is located, for 469 example "/systemhost/drivers/diskdrivers.drv", 471 3. The name of the driver, for example, "scsi". 473 The temptation is to form the first two items into a URL and embed 474 that into a service: URL. As an example which should be avoided, 476 service:ftp:/x3.bean.org/drivers/diskdrivers.drv;driver=scsi 478 is a service: URL which seems to indicate where to obtain the driver. 480 Rather, an abstract service-type SHOULD be used. The service type is 481 not "ftp", as the example indicates. Rather, it is "device-drivers". 482 The service: URL that should be used, consistent with the rules in 483 section [6], is the following: 485 service:device-drivers:ftp://x3.bean.org/drivers/diskdrivers.drv; 486 driver=scsi;platform=sys3.2-rs3000 488 Other URLs for the same service using other protocols are also 489 supported, as in: 491 service:device-drivers:tftp://x2.bean.org/vol3/disk/drivers.drv; 492 driver=scsi;platform=sys3.2-rs3000 494 service:device-drivers:http://www.bean.org/drivers/drivpak.drv; 495 driver=scsi;platform=sys3.2-rs3000 497 Using SLP, a search for the service type "device-drivers" may return 498 all of the three URLs listed above. The client selects the most 499 appropriate access protocol for the desired resource. 501 The fundamental requirement is that the abstract service type MUST 502 be well specified. This requirement is imposed so that program code 503 or human users have enough information to access the service. In 504 every case, a well-specified abstract type will include either an 505 access protocol and a network address where the service is available, 506 or an embedded URL for a standardized URL scheme that describes 507 how to access the service. In the example above, there are three 508 further requirements: A URL path is included for access protocols 509 indicating the document to download, and two attributes are included 510 to characterize the driver. 512 3. Syntax and Semantics of Service Type Specifications 514 Service type specifications are documents in a formal syntax defining 515 properties important to service registration. These properties are: 517 1. General information on the service type specification itself, 519 2. The syntax of the service type-specific part of the service URL, 521 3. The definition of attributes associated with a service. 523 The service type specification document is the service type template. 525 The following subsections describe the syntax and semantics of 526 service type templates. 528 3.1. Syntax of Service Type Templates 530 Service template documents are encoded in a simple form. They may be 531 translated into any language or character set, but the template used 532 for standardization MUST be encoded in the UTF8 [15] transformation 533 of the Unicode Character set [16] and written in English. 535 A template document begins with a block of text assigning values to 536 five document identification items. The five identification items 537 can appear in any order within the block, but conventionally the 538 "type" item, which assigns the service type name, occurs at the very 539 top of the document in order to provide context for the rest of 540 the the document. The attribute definition item occurs after the 541 document identification items. 543 All items end with a blank line. The reserved characters are ";", 544 "%", "=", ",", "#", LF, and CR. Reserved characters MUST be escaped. 545 The escape sequence is the same as described in [6]. 547 The service template is encoded in a UTF8 character set, but 548 submitted as a part of an internet-draft, which is encoded in ASCII 549 characters. All characters which are outside of the ASCII range MUST 550 be escaped using the % HEX HEX syntax. For example, the letter e 551 accent aigue would be represented as "%c3%a9". Unfortunately, this 552 will detract from the readability of the service template in the 553 internet draft. Hopefully some public domain tools will emerge for 554 translating escaped UTF8 characters into humanly readable ones. 556 Values in value lists are separated by commas. A value list is 557 terminated by a newline not preceded by a comma. If the newline is 558 preceded by a comma, the value list is interpreted to continue onto 559 the next line. 561 Attribute identifiers, attribute type names, and flags are all 562 case insensitive. For ease of presentation, upper and lower case 563 characters can be used to represent these in the template document. 564 Newlines are significant in the grammar. They delimit one item from 565 another, as well as separating parts of items internally. 567 String values are considered to be a sequence of non-whitespace 568 tokens potentially with embedded whitespace, separated from each 569 other by whitespace. Commas delimit lists of strings. String values 570 are trimmed so as to reduce any sequence of white space interior to a 571 string to a single white space. Preceding or trailing white space is 572 removed. For example: 574 " some value , another example " 576 is trimmed to 577 "some value" and "another example". 579 Note that there can be no ambiguity in string tokenization because 580 values in value lists are separated by a comma. String tokens are 581 not delimited by double quotes (") as is usually the case with 582 programming languages. 584 Attribute tags and values are useful for directory look-up. In this 585 case, decoding of character escapes and trimming white space MUST 586 be performed before string matching. In addition, string matching 587 SHOULD be case insensitive. 589 Templates obey the following ABNF [9] grammar: 591 template = tem-attrs attr-defs 592 tem-attrs = schemetype schemevers schemelang 593 schemetext schemeurl 594 schemetype = "type" "=" scheme termdef 595 schemevers = "version" "=" version-no termdef 596 schemelang = "language" "=" langtag termdef 597 schemetext = "description" "=" newline desc-text termdef 598 schemeurl = "url-syntax" "=" newline url-bnf termdef 599 url-bnf = *[ com-chars ] 600 ; An ABNF describing the production 601 ; in the service: URL grammar of Section 2.1. 602 scheme = service-type [ "." naming-auth ] 603 service-type = scheme-name 604 naming-auth = scheme-name 605 scheme-name = alpha [1*schemechar] [ "." 1*schemechar ] 606 schemechar = alpha / digit / "-" / "+" / 607 version-no = 1*digit "." 1*digit 608 langtag = 2*lower-alpha ;see [4] 609 desc-text = *[ com-chars ] 610 ; A block of free-form text for reading by 611 ; people describing the service in a short, 612 ; informative manner. 613 termdef = newline newline 614 attr-defs = *( attr-def / keydef ) 615 attr-def = id "=" attrtail 616 keydef = id "=" "keyword" newline [help-text] newline 617 attrtail = type flags newline [value-list] [help-text] 618 [value-list] newline 619 id = 1*attrchar 620 type = "string" / "integer" / "boolean" / "opaque" 621 flags = ["m"/"M"] ["l"/"L"] ["o"/"O"] ["x"/"X"] 622 value-list = value newline / value "," value-list / 623 value "," newline value-list 624 help-text = 1*( "#" help-line ) 625 ; A block of free-form text for reading by 626 ; people describing the attribute and 627 ; its values. 628 help-line = *[ com-chars ] newline 629 attrchar = schemechar / ":" / "_" / "$" / "~" / "@" / "." / 630 "|" / "<" / ">" / "*" / "&" 631 value = string / integer / boolean / opaque 632 string = safe-char *[safe-char / white-sp] safe-char 633 integer = [ "+" | "-" ] 1*digit 634 boolean = "true" / "false" 635 opaque = "\FF" 1*( "\" hex hex) 636 ; Each byte of the opaque value is expressed 637 ; as a pair of hexidecimal digits. 638 com-chars = safe-char / white-sp / "," / ";"/ "%" 639 safe-char = attrchar / escaped / " " / "!" / '"' / "'" / 640 "|" / "(" / ")" / "+" / "-" / "." / ":" / 641 "=" / "?" / "[" / "]" / "{" / "/" / "{" / 642 "$" 643 ; All UTF8 printable characters are 644 ; included except ",", "%", ";", and "#". 645 escaped = "%" hex hex 646 hex = digit / "A" / "B" / "C" / "D" / "E" / 647 "a" / "b" / "c" / "d" / "e" 648 white-sp = space / tab 649 newline = CR / ( CR LF ) 651 3.2. Semantics of Service Type Templates 653 The service type template defines the service attributes and service: 654 URL syntax for a particular service type. The attribute definition 655 includes the attribute type, default values, allowed values and other 656 information. 658 3.2.1. Definition of a Service Template 660 There are six items included in the service template. The semantics 661 of each item is summarized below. 663 - type 665 The scheme name of the service scheme. The scheme name consists 666 of the service type name and an optional naming authority name, 667 separated from the service type name by a period. See 3.2.2 for 668 the conventions governing service type names. 670 - version 671 The version number of the service type specification. 673 - language 675 The language of the service type specification. 677 - description 679 A description of the service suitable for inclusion in text read 680 by people. 682 - url-syntax 684 The syntax of the service type-specific URL part of the service: 685 URL. 687 - attribute definitions 689 A collection of zero or more definitions for attributes 690 associated with the service in service registrations. 692 Each of the following subsections deals with one of these items. 694 3.2.2. Service Type 696 The service scheme consists of the service type name and an optional 697 naming authority name separated from the service type name by a 698 period. The service scheme is a string that is appended to the 699 'service:' URL scheme identifier, and is the value of the "type" 700 item in the template document. If the naming authority name is 701 absent it is assumed to be IANA. 703 3.2.3. Service Type Language 705 The service type language is a RFC 1766 Language Tag defining the 706 language of the template [4] and is the value of the "language" item. 708 3.2.4. Version Number 710 The version number of the service type template is the value of the 711 "version" item. A draft proposal starts at 0.0, and the minor number 712 increments once per revision. A standardized template starts at 1.0. 713 Additions of optional attributes add one to the minor number, and 714 additions of required attributes, changes of definition, or removal 715 of attributes add one to the major number. The intent is that an 716 old service template still accurately, if incompletely, defines the 717 attributes of a service registration if the template only differs 718 from the registration in its minor version. See Section 4 for more 719 detail on how to use the version attribute. 721 3.2.5. Description 723 The description is a block of text readable by people in the language 724 of the template and is the value of the "description" item. It 725 should be sufficient to identify the service to human readers and 726 provide a short, informative description of what the service does. 728 If the service type corresponds to a particular protocol, the 729 protocol specification must be cited here. The protocol need not be 730 a standardized protocol. The template might refer to a proprietary 731 specification, and refer the reader of the template to a contact 732 person for further information. 734 3.2.6. Syntax of the Service Type-specific URL Part 736 The syntax of the service type-specific part of the service: 737 URL is provided in the template document as the value of the 738 "url-syntax" item. The field of the service: URL is 739 designed to provide additional information to locate a service when 740 the field is not sufficient. The field 741 distinguishes URLs of a particular service type from those of another 742 service type. For instance, in the case of the lpr service type, the 743 must include the queue name [13], but other service types 744 may not require this information. 746 The syntax for the field MUST accompany the definition 747 of a new service type, unless the URL scheme has already been 748 standardized and is not a service: URL. The syntax is included in the 749 template document as an ABNF [9] following the rules for URL syntax 750 described in [6]. There is no requirement for a service scheme to 751 support a . The field can be very simple, 752 or even omitted. If the URL scheme has already been standardized, 753 the "url-syntax" item SHOULD include a reference to the appropriate 754 standardization documents. Abstract service types may defer this 755 field to the template documents describing their concrete instances. 757 3.2.7. Attribute Definition 759 The bulk of the template is typically devoted to defining service 760 type-specific attributes. An attribute definition precisely 761 specifies the attribute's type, other restrictions on the attribute 762 (whether it is multi-valued, optional, etc), some text readable by 763 people describing the attribute, and lists of default and allowed 764 values. The only required information is the attribute's type, the 765 rest are optional. Registration, deregistration and the use of 766 attributes in queries can be accomplished using the Service Location 767 Protocol [14] or other means, and discussion of this is beyond the 768 scope of the document. 770 Attributes are used to convey information about a given service for 771 purposes of differentiating different services of the same type. 772 They convey information to be used in the selection of a particular 773 service to establish communicate with, either through a program 774 offering a human interface or programmatically. Attributes can be 775 encoded in different character sets and in different languages. The 776 procedure for doing this is described in Section 6. 778 An attribute definition begins with the specification of the 779 attribute's identifier and ends with a single empty line. Attributes 780 definitions have five components (in order of appearance in a 781 definition): 783 1. An attribute identifier which acts as the name of the attribute, 785 2. Attribute descriptors (type and flags), 787 3. An optional list of values which are assigned to the attribute by 788 default, 790 4. An optional block of text readable by people providing a short, 791 informative description of the attribute, 793 5. An optional list of allowed values which restrict the value or 794 values the attribute can take on. 796 3.2.7.1. The Attribute Identifier 798 An attribute definition starts with the specification of the 799 attribute's identifier. The attribute's identifier functions as the 800 name of the attribute. Note that the characters used to compose an 801 attribute identifier are restricted to those characters considered 802 unrestricted for inclusion in a URL according to [6]. The reason 803 is that services can display prominent attributes in their service: 804 URL registrations. Each attribute identifier must be unique in the 805 template. Since identifiers are case folded, upper case and lower 806 case characters are the same. 808 3.2.7.2. The Attribute Type 810 Attributes can have one of five different types: string, integer, 811 boolean, opaque, or keyword. The attribute's type specification is 812 separated from the attribute's identifier by an equal sign ("=") and 813 follows the equal sign on the same line. The string, signed integer, 814 and boolean types have the standard programming language or database 815 semantics. Integers are restricted to those signed values that can 816 be represented in 32 bits. The character set used to represent 817 strings is not specified at the time the template is defined, but 818 rather is determined by the service registration. Booleans have 819 the standard syntax. Opaques are escaped bytes that can be used 820 to represent any other kind of data. Keywords are attributes that 821 have no characteristics other than their existence (and possibly the 822 descriptive text in their definition). 824 Keyword and boolean attributes impose restrictions on the following 825 parts of the attribute definition. Keyword attribute definitions 826 MUST have no flag information following the type definition, nor any 827 default or allowed values list. Boolean attributes are single value 828 only, i.e., multi-valued boolean attributes are not allowed. 830 3.2.7.3. Attribute Flags 832 Flags determine other characteristics of an attribute. With the 833 exception of keyword attributes, which may not have any flags, 834 flags follow the attribute type on the same line as the attribute 835 identifier, and are separated from each other by whitespace. Flags 836 may appear in any order after the attribute type. Other information 837 must not follow the flags, and only one flag identifier of a 838 particular flag type is allowed per attribute definition. 840 The semantics of the flags are as follows: 842 - o or O 844 Indicates that the attribute is optional. If this flag is 845 missing, the attribute is required in every service registration. 847 - m or M 849 Indicates that the attribute can take on multiple values. If 850 this flag is present, every value in a multi-valued attribute 851 has the same type as the type specified in the type part of the 852 attribute definition. Boolean attributes must not include this 853 flag. 855 - l or L 856 Indicates that attribute is literal, i.e. is not meant to be 857 translated into other languages. If this flag is present, the 858 attribute is not considered to be readable by people and should 859 not be translated when the template is translated. See Section 6 860 for more information about translation. 862 - x or X 864 Indicates that clients SHOULD include the indicated attribute 865 in requests for services. Neglecting to include this attribute 866 will not sufficiently differentiate the service. If services are 867 obtained without selecting this attribute they will quite likely 868 be useless to the client. 870 The values for multivalued attributes are an unordered set. 871 Deletions of individual values from a multivalued attribute are not 872 supported, and deletion of the attribute causes the entire set of 873 values to be removed. 875 3.2.7.4. Default Value or List 877 If the attribute definition includes a default value or, in the 878 case of multivalued attributes, a default values list, it begins 879 on the second line of the attribute definition and continues 880 over the following lines until a line ends without a comma. As a 881 consequence, newlines cannot be embedded in values unless escaped. 882 See Section 2.1. 884 Particular attribute types and definitions restrict the default 885 values list. Keyword attributes must not have a list of defaults. 886 If an optional attribute's definition has an allowed values list, 887 then a default value or list is not optional but required. The 888 motivation for this is that defining an attribute with an allowed 889 values list is meant to restrict the values the attribute can take 890 on, and requiring a default value or list assures that the default 891 value is a member of the given set of allowed values. 893 The default value or list indicates what values the attribute is 894 given if no values are assigned to the attribute when a service 895 is registered. If an optional attribute's definition includes no 896 default value or list, the following defaults are assigned: 898 1. String values are assigned the empty string, 900 2. Integer values are assigned zero, 902 3. Boolean values are assigned false, 903 4. Opaque values are assigned a byte array containing no values, 905 5. Multi-valued attributes are initialized with a single value. 907 For purposes of translating nonliteral attributes, the default values 908 list is taken to be an ordered set, and translations MUST maintain 909 that order. 911 3.2.7.5. Descriptive Text 913 Immediately after the default values list, if any, a block of 914 descriptive text SHOULD be included in the attribute definition. 915 This text is meant to be readable by people, and should include 916 a short, informative description of the attribute. It may also 917 provide additional information, such as a description of the allowed 918 values. This text is primarily designed for display by interactive 919 browsing tools. The descriptive text is set off from the surrounding 920 definition by a crosshatch character ("#") at the beginning of 921 the line. The text should not, however, be treated as a comment 922 by parsing and other tools, since it is an integral part of the 923 attribute definition. Within the block of descriptive text, the text 924 is transferred verbatim, including indentation and line breaks, so 925 any formatting is preserved. 927 3.2.7.6. Allowed Values List 929 Finally, the attribute definition concludes with an optional 930 allowed values list. The allowed values list, if any, follows the 931 descriptive text, or, if the descriptive text is absent, the initial 932 values list. The syntax of the allowed values list is identical to 933 that of the initial values list. The allowed values list is also 934 terminated by a line that does not end in a comma. If the allowed 935 values list is present, assignment to attributes is restricted to 936 members of the list. 938 As with the default values list, the allowed values list is also 939 considered to be an ordered set for purposes of translation. 941 3.2.7.7. Conclusion of An Attribute Definition 943 An attribute definition concludes with a single empty line. 945 4. A Process For Standardizing New Service Types 947 New service types can be suggested simply by providing a service type 948 template and a short description about how to use the service. The 949 template MUST have its "version" template attribute set to 0.0. 951 MAJOR revision numbers come before the '.', MINOR revision numbers 952 come after the '.'. 954 The minor version number increments once with each change until it 955 achieves 1.0. There is no guarantee any version of the service 956 template is backward compatible before it reaches 1.0. 958 Once a service template has reached 1.0, the definition is "frozen" 959 for that version. New templates must be defined, of course, to 960 refine that definition, but the following rules must be followed: 962 A MINOR revision number signifies the introduction of a compatible 963 change. A MAJOR revision number signifies the introduction of an 964 incompatible change. This is formalized by the following rules: 966 - Any new optional attribute defined for the template increases 967 the minor version number by one. All other attributes for the 968 version must continue to be supported as before. A client which 969 supports 1.x can still use later versions of 1.y (where x "." "." 1030 Each of these fields are defined in Section 2. They correspond 1031 to the values of the template fields "type", "version" and 1032 "lang". The files for the example templates in this 1033 document are called "foo.0.0.en", "Net-Transducer.0.0.en" and 1034 "Net-Transducer:Thermomoter.0.0.en". See Section A. 1036 The reviewer will ensure that the template submission to IANA has the 1037 correct version number in the "version" and "lang" fields. 1039 No service type template will be accepted for inclusion in the 1040 service template registry unless the Internet Draft submitted 1041 includes a security considerations section and contact information 1042 for the template document author. 1044 The IANA will maintain a registry containing both the service type 1045 templates, and the template description document containing the 1046 service type template, including all previous versions. The IANA 1047 will receive notice by email from the reviewers, which will contain a 1048 reference to the Internet Draft that contains the service template. 1049 This Internet Draft will be edited to remove the Internet Draft 1050 headers and replace them with a simple header stating "This document 1051 contains a Service Type Template." 1053 Neither the reviewer nor the IANA will take any position on claims of 1054 copyright or trademark issues with regard to templates.' 1056 6. Internationalization Considerations 1058 The service: URL must be encoded using the rules set forth in [6]. 1059 The character set encoding is limited to specific ranges within the 1060 US-ASCII character set [5]. 1062 The template is encoded in UTF8 characters. 1064 6.1. Language Identification and Translation 1066 The language used in attribute strings should be identified using the 1067 "language" template item as defined by [4]. 1069 A program can translate a service registration from one language to 1070 another provided it has both the template of the language for the 1071 registration and the template of the desired target language. All 1072 standardized attributes are in the same order in both templates. 1073 All non-arbitrary strings, including the descriptive help text, is 1074 directly translatable from one language to another. Non-literal 1075 attribute definitions, attribute identifiers, attribute type names, 1076 attribute flags, and the boolean constants "true" and "false" are 1077 never translated. Translation of attribute identifiers is prohibited 1078 because, as with domain names, they can potentially be part of a 1079 service: URL and therefore their character set is restricted. In 1080 addition, as with variable identifiers in programming languages, they 1081 could become embedded into program code. 1083 All strings used in attribute values are assumed translatable unless 1084 explicitly defined as being literal, so that best effort translation 1085 (see below) does not modify strings which are meant to be interpreted 1086 by a program, not a person. 1088 There are two ways to go about translation: standardization and best 1089 effort. 1091 When the service type is standardized, more than one document can 1092 be submitted for review. One service type description is approved 1093 as a master, so that when a service type template is updated in one 1094 language, all the translations (at least eventually) reflect the same 1095 semantics. 1097 If no document exists describing the standard translation of the 1098 service type, a 'best effort' translation for strings should be done. 1100 7. Security Considerations 1102 Service type templates provide information that is used to interpret 1103 information obtained by the Service Location Protocol. If these 1104 templates are modified or false templates are distributed, services 1105 may not correctly register themselves, or clients might not be able 1106 to interpret service information. 1108 The service: URLs themselves specify the service access point and 1109 protocol for a particular service type. These service: URLs could 1110 be distributed and indicate the location of a service other than 1111 that normally want to used. The Service Location Protocol [14] 1112 distributes service: URLs and has an authentication mechanism that 1113 allows service: URLs of registered services to be signed and for the 1114 signatures to be verified by clients. 1116 Each Service Template will include a security considerations section 1117 which will describe security issues with using the service scheme for 1118 the specific Service Type. 1120 A. Service Template Examples 1122 The text in the template example sections is to be taken as being a 1123 single file. They are completely fictitious (ie. the examples do 1124 not represent real services). 1126 The FOO example shows how to use service templates for an application 1127 that has very few attributes. Clients request the FOO server where 1128 their user data is located by including their user name as the value 1129 of the user attribute. 1131 The Net-Transducer example shows how abstract service types are 1132 defined and how a corresponding concrete instance is defined. A 1133 system might support any of several NetTransducer services. Here we 1134 give only one concrete instance of the abstract type. 1136 It is not necessary to register concrete templates for an abstract 1137 service type if the abstract service type template is completely 1138 clear as to what possible values can be used as a concrete type, and 1139 what their interpretation is. 1141 A.1. FOO 1143 -------------------------template begins here----------------------- 1144 type=FOO 1146 version=0.0 1148 lang=en 1150 description= 1151 The FOO service URL provides the location of an FOO service. 1153 url-syntax= 1154 url-path= ; There is no URL path defined for a FOO URL. 1156 users= string M L O 1157 # The list of all users which the FOO server supports. 1159 groups= string M L O 1160 # The list of all groups which the FOO server supports. 1161 --------------------------template ends here------------------------ 1163 The Internet Draft describing the FOO scheme template must indicate 1164 contact information and security considerations, e.g., 1166 contact="Erik Guttman" 1168 security considerations= 1169 If the USER and GROUPS attributes are included a 1170 possibility exists that the list of identities for users or groups 1171 can be discovered. This information would otherwise be difficult 1172 to discover. 1174 A.2. Abstract Service Type: Net-Transducer 1176 The Internet Draft for the service type template contains the 1177 following text: 1179 -------------------------template begins here----------------------- 1180 type=Net-Transducer 1182 version=0.0 1184 lang=en 1185 description= 1186 This is an abstract service type. The purpose of the Net- 1187 Transducer service type is to organize into a single category 1188 all network enabled Transducers which have certain properties. 1190 url-syntax= 1191 url-path= ; Depends on the concrete service type. 1192 ; See these templates. 1194 sample-units= string L 1195 # The units of sample that the Transducer provides, for instance 1196 # C (degrees Celsius), V (Volts), kg (Kilograms), etc. 1198 sample-resolution= string L 1199 # The resolution of the Transducer. For instance, 10^-3 means 1200 # that the Transducer has resolution to 0.001 unit. 1202 sample-rate= integer L 1203 # The speed at which samples are obtained per second. For 1204 # instance 1000 means that one sample is obtained every millisecond. 1206 --------------------------template ends here------------------------ 1208 In addition, the following format might be used for the needed 1209 contact and security considerations information. 1210 .......... 1212 contact="Erik Guttman" 1214 security considerations= 1215 See the security considerations of the concrete service types. 1217 A.3. Concrete Service Type: Net-Transducer:Thermometer 1219 -------------------------template begins here----------------------- 1220 type=service:Net-Transducer:Thermometer 1222 version=0.0 1224 lang=en 1226 description= 1227 The Thermometer is a Net-Transducer capable of reading temperature. 1228 The data is read by opening a TCP connection to one of the ports 1229 in the service URL and reading an ASCII string until an NULL 1230 character is encountered. The client may continue reading data at 1231 no faster than the sample-rate, or close the connection. 1233 url-syntax= 1234 url-path = ; ports 1235 port-list = ";ports=" port-list 1236 ports = port / port "," ports 1237 ; See the Service URL production rule. 1238 ; These are the ports connections can be made on. 1240 location-description=string 1241 # The location where the Thermometer is located. 1243 operator=string O 1244 # The operator to contact to have the Thermometer serviced. 1246 --------------------------template ends here------------------------ 1248 ......... 1250 contact="Erik Guttman" 1252 security considerations= 1253 There is no authentication of the Transducer output. Thus, 1254 the Thermometer output could easily be spoofed. 1256 A.4. service: URLs and SLP 1258 A user with an FOO enabled calendar application should not be 1259 bothered with knowing the address of their FOO server. The 1260 calendar client program can use SLP to obtain the FOO service: URL 1261 automatically, say 'service:foo://server1.nosuch.org', by issuing 1262 a Service Request. In the event that this FOO server failed, the 1263 Calendar client can issue the same service request again to find the 1264 backup FOO server, say 'service:foo://server2.nosuch.org'. In both 1265 cases, the service: URL conforms to the FOO service template as do 1266 the associated attributes (user and group.) 1268 A network thermometer could be advertised as: 1270 URL = service:net-transducer:thermometer://v33.test/ports=3211 1271 Attributes = (location-description=Missile bay 32), 1272 (operator=Joe Agent), (sample-units=C), 1273 (sample-resolution=10^-1),(sample-rate=10) 1275 This might be very useful for a technician who wanted to find a 1276 Thermometers in Missile bay 32, for example. 1278 B. Full Copyright Statement 1280 Copyright (C) The Internet Society (1997). All Rights Reserved. 1282 This document and translations of it may be copied and furnished to 1283 others, and derivative works that comment on or otherwise explain it 1284 or assist in its implmentation may be prepared, copied, published 1285 and distributed, in whole or in part, without restriction of any 1286 kind, provided that the above copyright notice and this paragraph 1287 are included on all such copies and derivative works. However, 1288 this document itself may not be modified in any way, such as by 1289 removing the copyright notice or references to the Internet Society 1290 or other Internet organizations, except as needed for the purpose 1291 of developing Internet standards in which case the procedures 1292 for copyrights defined in the Internet Standards process must be 1293 followed, or as required to translate it into languages other than 1294 English. 1296 The limited permissions granted above are perpetual and will not be 1297 revoked by the Internet Society or its successors or assigns. 1299 This document and the information contained herein is provided on an 1300 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1301 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1302 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1303 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1304 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1306 C. Acknowledgments 1308 Ryan Moats suggestions were very useful in producing this document. 1309 Thanks to Michael Day, Leland Wallace and Ryan Moats for assisting 1310 with the IPX and AppleTalk address syntax portions of this document. 1312 References 1314 [1] Protocol and service names, October 1994. 1315 ftp://ftp.isi.edu/in-notes/iana/assignments/service-names. 1317 [2] Address family numbers, October 1995. 1318 ftp://ftp.isi.edu/in-notes/iana/assignments/address-family-numbers. 1320 [3] Port numbers, July 1997. 1321 ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers. 1323 [4] H. Alvestrand. Tags for the Identification of Languages. RFC 1324 1766, March 1995. 1326 [5] ANSI. Coded Character Set -- 7-bit American Standard code for 1327 Information Interchange. X3.4-1986, 1986. 1329 [6] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource 1330 Locators (URL): Generic Syntax and Semantics. RFC1738 as 1331 amended by RFC1808 1333 [7] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource 1334 Locators (URL). RFC 1738, December 1994. 1336 [8] N. Freed and N. Borenstein. Multipurpose Internet Mail 1337 Extensions (MIME) Part One: Format of Internet Message Bodies. 1338 RFC 2045, November 1996. 1340 [9] D. Crocker and P Overell. Augmented BNF for Syntax 1341 Specifications: ABNF. RFC 2234, November 1997 1343 [10] A. Gulbrandsen and P. Vixie. A DNS RR for specifying the 1344 location of services (DNS SRV). RFC 2052, October 1996. 1346 [11] J. Myers. Simple Authentication and Security Layer (SASL). RFC 1347 2222, October 1997. 1349 [12] J. G. Myers. ACAP -- Application Configuration Access Prototol. 1350 RFC 2244, November 1997. 1352 [13] Pete St. Pierre. Definition of lpr: URLs for use with Service 1353 Location. draft-ietf-svrloc-printer-scheme-02.txt, November 1354 1997. (work in progress). 1356 [14] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 1357 Location Protocol. RFC 2165, July 1997. 1359 [15] F. Yergeau. UTF-8, a transformation format of unicode and ISO 1360 10646. RFC 2044, October 1996. 1362 [16] Unicode Technical Report #4. The unicode standard, version 2.0. 1363 Technical Report ISBN 0-201-48345-9, The Unicode Consortium, 1364 1996. 1366 [17] Apple Computer. Inside Macintosh: Text Addison Wesley, 1993 1368 [18] G. Sidhu, R. Andrews, A. Oppenheimer Inside AppleTalk, Second 1369 Edition Addison Wesley, 1991 1371 [19] Novell, Inc. IPX RIP and SAP Router Specification Part Number 1372 107-000029-001, Version 1.30, May 23, 1996 1374 Authors' Addresses 1376 Questions about this memo can be directed to: 1378 Erik Guttman Charles E. Perkins James Kempf 1379 Sun Microsystems Sun Microsystems Sun Microsystems 1380 Bahnstr. 2 901 San Antonio Rd. 901 San Antonio Rd. 1381 74915 Waibstadt Palo Alto, CA, 94303 Palo Alto, CA, 94303 1382 Germany USA USA 1384 +49 7263 911484 1 650 786 6464 1 650 786 5890 1385 1 650 786 6445 (fax) 1 650 786 6445 (fax) 1386 erik.guttman@sun.com charles.perkins@sun.com james.kempf@sun.com