idnits 2.17.1 draft-ietf-svrloc-service-scheme-07.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 50: '... They SHOULD be used by administrati...' RFC 2119 keyword, line 178: '...en the service type name SHOULD either...' RFC 2119 keyword, line 219: '... The syntax of the service: URL MUST conform to [5]. Moreover, the...' RFC 2119 keyword, line 305: '...attr-list> field MAY appear at the end...' RFC 2119 keyword, line 344: '... Service: URLs SHOULD be selected ac...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1321 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) == 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. '11' ** Obsolete normative reference: RFC 2044 (ref. '13') (Obsoleted by RFC 2279) Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 8 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 2 February 1998 Sun Microsystems 6 Service Templates and service: Schemes 7 draft-ietf-svrloc-service-scheme-07.txt 9 Status of This Memo 11 This document is a submission by the Service Location Working Group 12 of the Internet Engineering Task Force (IETF). Comments should be 13 submitted to the srvloc@corp.home.net mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at 24 any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check 28 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 29 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (North 30 Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), 31 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 33 Abstract 35 The ''service:'' URL scheme name is used to define URLs (called 36 ''service: URLs'' in this document) that are primarily intended to 37 be used by the Service Location Protocol in order to distribute 38 service access information. These schemes provide an extensible 39 framework for client-based network software to obtain configuration 40 information required to make use of network services. When 41 registering a service: URL, the URL is accompanied by a set of 42 well-defined attributes which define the service. These attributes 43 convey configuration information to client software, or service 44 characteristics meaningful to end users. 46 This document describes a formal procedure for defining and 47 standardizing new service types and attributes for use with the 48 ''service:'' scheme. The formal descriptions of service types and 49 attributes are templates that are human and machine understandable. 50 They SHOULD be used by administrative tools to parse service 51 registration information and by client applications to provide 52 localized translations of service attribute strings. 54 Contents 56 Status of This Memo i 58 Abstract i 60 1. Introduction 2 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Service Location Protocol . . . . . . . . . . . . . . . . 4 64 2. Service URL Syntax and Semantics 4 65 2.1. Service URL Syntax . . . . . . . . . . . . . . . . . . . 4 66 2.2. Service URL Semantics . . . . . . . . . . . . . . . . . . 5 67 2.3. Use of service: URLs . . . . . . . . . . . . . . . . . . 7 68 2.4. Specifying the Service Type-Specific URL Syntax . . . . . 7 69 2.5. Abstract Service Types . . . . . . . . . . . . . . . . . 8 70 2.5.1. Advertising Abstract Service Types . . . . . . . 8 72 3. Service Templates 9 73 3.1. Syntax of Service Type Templates . . . . . . . . . . . . 10 74 3.2. Semantics of Service Type Templates . . . . . . . . . . . 12 75 3.2.1. Definition of a Service Template . . . . . . . . 13 76 3.2.2. Service Type . . . . . . . . . . . . . . . . . . 13 77 3.2.3. Version Number . . . . . . . . . . . . . . . . . 13 78 3.2.4. Service Type Language . . . . . . . . . . . . . . 14 79 3.2.5. Description . . . . . . . . . . . . . . . . . . . 14 80 3.2.6. Syntax of the Service Type-specific URL Part . . 14 81 3.2.7. Attribute Definition . . . . . . . . . . . . . . 15 83 4. A Process For Standardizing New Service Types 19 85 5. IANA Considerations 20 87 6. Internationalization Considerations 21 88 6.1. Language Identification and Translation . . . . . . . . . 21 90 7. Security Considerations 22 92 A. Service Template Examples 22 93 A.1. FOO . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 A.2. Abstract Service Type: Net-Transducer . . . . . . . . . 23 95 A.3. Concrete Service Type: Net-Transducer:Thermometer . . . 24 96 A.4. service: URLs and SLP . . . . . . . . . . . . . . . . . . 25 98 B. Full Copyright Statement 27 99 C. Acknowledgments 27 101 1. Introduction 103 This document describes a URL scheme, called service: URL, which uses 104 a formal notation to define network access information for network 105 services. In addition it describes how to define a set of attributes 106 to associate with a service: URL. These attributes will allow end 107 users and programs to select between network services of the same 108 type that have different capabilities. The attributes are defined in 109 a template document that is readable by people and machines. 111 A client uses attributes to select a particular service. Service 112 selection occurs by obtaining the service: URL that offers the right 113 configuration for the client. Service type templates define the 114 syntax of service: URLs for a particular service type, as well as the 115 attributes which accompany a service: URL in a service registration. 117 Templates are used for the following purposes: 119 Standardization 120 The template is reviewed before it is standardized. Once 121 it is standardized, all versions of the template are 122 archived by IANA. 124 Service Registration 125 Servers making use of the Service Location Protocol [12] 126 register themselves and their attributes. They use the 127 templates to generate the service registrations. In 128 registering, the service must use the specified values 129 for its attributes. 131 Client presentation of Service Information 132 Client applications may display service information. The 133 template provides type information and explanatory text 134 which may be helpful in producing user interfaces. 136 Internationalization 137 Entities with access to the template for a given service 138 type in two different languages may translate between the 139 two languages. 141 A service may register itself in more than one language 142 using templates, though it has been configured by an 143 operator who registered service attributes in a single 144 language. 146 All grammar encoding follows the Augmented BNF (ABNF) [8] for syntax 147 specifications. 149 1.1. Terminology 151 This section introduces the following terminology: 153 service scheme 155 A URL scheme whose name starts with the string "service:" and 156 is followed by the service type name, constructed according to 157 the rules in this document. An example is "service:lpr:" for 158 the lpr print service [11]. 160 service: URL 162 A URL constructed according to the service scheme definition. 163 It typically provides at least the following: The name of an 164 access protocol, and an address locating this service. The 165 service: URL may include url path information specific to the 166 type of service, as well as attribute information encoded 167 according to the URL grammar. The service: URL is used by 168 the Service Location Protocol to register and discover the 169 location of services. It may be used by other protocols and in 170 documents as well. 172 service type 174 A name identifying the semantics by which the remainder of 175 the service: URL is to be understood. It may denote either a 176 particular network protocol, or an abstract service associated 177 with a variety of protocols. If the service type denotes a 178 particular protocol, then the service type name SHOULD either 179 be assigned the name of a particular well known port [2] by 180 convention or be the Assigned Numbers name for the service [1]. 182 abstract service type 184 A service type name which is associated with a variety of 185 different protocols. An example is given in Appendix A. 186 Section 2 discusses various ways that abstract types can be 187 accommodated. 189 service registration 191 A service: URL and optionally a set of attributes comprise 192 a service registration. This registration is made by or on 193 behalf of a given service. The URL syntax and attributes must 194 conform to the service template for the registered service. 196 service template 198 A formal description of the service attributes and service 199 scheme associated with a particular service type. 201 1.2. Service Location Protocol 203 The Service Location Protocol [12] allows service: URLs to be 204 registered and discovered. Service: URLs may be also used in other 205 contexts. Client applications discover service registrations by 206 issuing queries for services of a particular type, specifying the 207 attributes of the service: URLs to return. 209 Services may register themselves, or registrations may be made on 210 their behalf. These registrations contain a service: URL, and 211 possibly attributes and digital signatures. 213 2. Service URL Syntax and Semantics 215 This section describes the syntax and semantics of service: URLs. 217 2.1. Service URL Syntax 219 The syntax of the service: URL MUST conform to [5]. Moreover, the 220 field has been omitted from the production, since 221 plaintext transmission of passwords is discouraged. The 222 field is the service access point, and describes how to access the 223 service. Note that the syntax for the field depends upon the 224 service type definition. In addition, although both upper case and 225 lower case characters are recognized in the field 226 for convenience, the name is case-folded into lower case. Service 227 types are therefore not distinguished on the basis of case, so, for 228 example, "http" and "HTTP" designate the same service type. This is 229 consistent with general URL practice, as outlined in [6]. 231 The ABNF for a service: URL is: 233 service: URL = "service:" service-type ":" sap 234 service-type = abstract-type ":" url-scheme / concrete-type 235 abstract-type = type-name [ "." naming-auth ] 236 concrete-type = protocol [ "." naming-auth ] 237 type-name = resname 238 naming-auth = resname 239 url-scheme = resname 240 ; A recognized URL scheme name, standardized 241 ; either through common practice or through 242 ; approval of a standards body. 243 resname = alpha [ 1*(alpha / digit / "+" / "-") ] 244 sap = "//" site [ url-part ] 245 site = [ [ user "@" ] hostport ] 246 hostport = host [ ":" port ] 247 host = hostname / hostnumber 248 hostname = *( domainlabel "." ) toplabel 249 alphanum = alpha / digit 250 domainlabel = alphanum / alphanum *[alphanum / "-"] alphanum 251 toplabel = alpha / alpha *[ alphanum / "-" ] alphanum 252 hostnumber = ipv4-number / ipv6-number 253 ipv4-number = 1*3digit 3("." 1*3digit) 254 ipv6-number = 32hex 255 3digit = digit digit digit 256 port = 1*digit 257 ; A port number must be included if the 258 ; protocol field does not have an IANA 259 ; assigned port number. 260 user = *[ uchar / ";" / "+" / "&" / "=" ] 261 url-part = [ url-path ] [ attr-list ] 262 url-path = 1 * ( "/" *xchar ) 263 ; Each service type must define its own 264 ; syntax consistent with [5]. 265 attr-list = 1 * ( ";" attr-asgn ) 266 attr-asgn = attr-id / attr-id "=" attr-value 267 safe = "$" / "-" / "_" / "." / "~" 268 extra = "!" / "*" / "'" / "(" / ")" / "," / "+" 269 uchar = unreserved / escaped 270 xchar = unreserved / reserved / escaped 271 escaped = "%" hex hex 272 hex "a" / "b" / "c" / "d" / "e" / digit 273 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" 274 unreserved = alpha / digit / safe / extra 276 Certain characters must be escaped before use. To escape any 277 character, precede the two digits indicating its ASCII value by '%'. 279 2.2. Service URL Semantics 281 The service scheme-specific information following the "service:" 282 URL scheme identifier provides information necessary to access the 283 service. As described in the previous subsection, the form of a 284 service: URL is as follows: 286 service: URL = "service:"":" 288 where has the following form: 290 ///url-path;attr-list 292 As discussed in Section 1, the can be either a 293 concrete protocol name, or an abstract type name. 295 The field includes a site specification (the 296 field) in the format specified by [5]. The field is 297 typically either a domain name (DNS) or an IP network protocol 298 address for the service, and possibly a port number. Note that use 299 of DNS hostnames is preferred for ease of renumbering. 301 The field allows more information to be provided (by way of 302 and ) that can uniquely locate the service or 303 resource if the is not sufficient for that purpose. 305 An field MAY appear at the end of the field, 306 but is never required to exist in any service location registration. 307 The field is composed of a list of semicolon (";") 308 separated attribute assignments of the form: 310 attr-id "=" attr-value 312 or for keyword attributes: 314 attr-id 316 Attributes are part of service: URLs when the attributes are required 317 to access a particular service. For instance, an ACAP [10] service 318 might require that the client authenticate with it through Kerberos. 319 Including an attribute in the service registration allows the ACAP 320 client to make use of the correct SASL [9] authentication mechanism. 321 The ACAP server's registration might look like: 323 service:acap://some.where.net;authentication=KERBEROSV4 325 Note that there can be other attributes of an ACAP server which 326 are not appropriate to include in the URL. For instance, the list 327 of users who have access to the server is useful for selecting an 328 ACAP server, but is not required for a client to use the registered 329 service. 331 Attributes associated with the service: URL are not typically 332 included in the service: URL. They are stored and retrieved using 333 other mechanisms. The service: URL is uniquely identified with a 334 particular service agent or resource, and is used when registering or 335 requesting the attribute information. The Service Location Protocol 336 specifies how such information is registered by network services and 337 obtained by client software. 339 2.3. Use of service: URLs 341 A service: URL enables application agents to use a standardized 342 dynamic service access point discovery mechanism. 344 Service: URLs SHOULD be selected according to the suitability of 345 associated attributes. A client application can distinguish the most 346 preferable among several services of the same type by means of their 347 attributes. The client then uses the service: URL to communicate 348 directly to a service. 350 Attributes are specified with a formal service template syntax 351 described in Section 3. If a service: URL registration includes 352 attributes, the registering agent SHOULD also keep track of the 353 attributes which characterize the service. Registrations can be 354 checked against the formal attribute specification defined in the 355 template by the client or agent representing the client. 357 Service registration are typically done using the Service Location 358 Protocol [12] (SLP). SLP provides a mechanism for service: URLs to be 359 obtained dynamically, according to the service's attributes. 361 It is also possible to obtain service: URLs from documents and using 362 other protocols. In this case, the URL may not be accompanied by 363 the service attributes. The context in which the URL appears should 364 make it clear, if possible, when the service is appropriate to use. 365 For example, in a mail message, a service might be recommended for 366 use when the user is in a branch office. Or, an HTML document might 367 include a service: URL as a pointer to a service, describing in text 368 what the service does and who is authorized to use it. 370 2.4. Specifying the Service Type-Specific URL Syntax 372 When a service type is specified, the specification includes the 373 definition of the syntax for all URLs that are registered by services 374 of that particular type. For instance, the "lpr" service type may be 375 defined with service: URLs in the following form: 377 service:printer:lpr://
/ 379 The section of the URL after the address of the printer: 381 "/" 383 is specific to the lpr service type and corresponds to the 384 field of the general service: URL syntax. This part is 385 specified when the lpr service type is specified. 387 2.5. Abstract Service Types 389 An abstract service type is a service type that can be implemented by 390 a variety of different service agents. 392 In order to register a service: URL for an abstract service type, the 393 'abstract-type' grammar rule described in section 3.1 is used. This 394 will result in a URL which includes enough information to use the 395 service, namely, the protocol, address and path information. Unlike 396 'concrete' service: URLs, however, the service type is not enough 397 to determine the service access. Rather, an abstract service type 398 denotes a class of service types. 400 2.5.1. Advertising Abstract Service Types 402 Some services may make use of several protocols that are in common 403 use and are distinct services in their own right. In these cases an 404 abstract service type is appropriate. What is essential is that all 405 the required information for the service is clearly defined. 407 For example, suppose a network service is being developed for 408 dynamically loading device drivers. The client requires the 409 following four pieces of information before it can successfully load 410 and execute the driver: 412 1. The protocol used to load the driver code, for example, "ftp", 413 "http" or "tftp" 415 2. A pathname identifying where the driver code is located, for 416 example "/systemhost/drivers/diskdrivers.drv", 418 3. The name of the driver, for example, "scsi". 420 4. The name of the platform, for example, "sys3.2-rs3000". 422 The temptation is to form the first two items into a URL and embed 423 that into a service: URL. As an example which should be avoided, 425 service:ftp://x3.bean.org/drivers/diskdrivers.drv;driver=scsi; 426 platform=sys3.2-rs3000 428 is a service: URL which seems to indicate where to obtain the driver. 430 Rather, an abstract service-type SHOULD be used. The service type is 431 not "ftp", as the example indicates. Rather, it is "device-drivers". 432 The service: URL that should be used, consistent with the rules in 433 section [6], is the following: 435 service:device-drivers:ftp://x3.bean.org/drivers/diskdrivers.drv; 436 driver=scsi;platform=sys3.2-rs3000 438 Other URLs for the same service using other protocols are also 439 supported, as in: 441 service:device-drivers:tftp://x2.bean.org/vol3/disk/drivers.drv; 442 driver=scsi;platform=sys3.2-rs3000 444 service:device-drivers:http://www.bean.org/drivers/drivpak.drv; 445 driver=scsi;platform=sys3.2-rs3000 447 Using Service Location Protocol, a service request for the service 448 type "device-drivers" may return all of the three URLs listed above. 449 The attributes associated with the services desired are used to 450 formulate the queries, as: 452 = service:device-drivers 453 = (& (driver=scsi)(platform=sys3.2-rs3000)) 455 This query will return all three URLs listed above. If only 456 the 'tftp' URL was desired, would be set to 457 "service:device-drivers:tftp". 459 The fundamental requirement is that the abstract service type MUST 460 specify enough information to access the service. In every case, a 461 well-specified abstract type will include either an access protocol 462 and a network address where the service is available, or an embedded 463 URL for a standardized URL scheme that describes how to access the 464 service. In the example above, there are three further requirements: 465 A URL path is included for access protocols indicating the document 466 to download, and two attributes are included to characterize the 467 driver. 469 3. Service Templates 471 Service templates are documents in a formal syntax defining 472 properties important to service registration. These properties are: 474 1. General information on the service type specification itself, 476 2. The syntax of the service type-specific part of the service URL, 477 3. The definition of attributes associated with a service. 479 The service type specification document is the service type template. 481 The following subsections describe the syntax and semantics of 482 service type templates. 484 3.1. Syntax of Service Type Templates 486 Service template documents are encoded in a simple form. They may be 487 translated into any language or character set, but the template used 488 for standardization MUST be encoded in the ASCII subset of UTF8 [13] 489 and be in English. 491 A template document begins with a block of text assigning values to 492 five document identification items. The five identification items 493 can appear in any order within the block, but conventionally the 494 "type" item, which assigns the service type name, occurs at the very 495 top of the document in order to provide context for the rest of 496 the the document. The attribute definition item occurs after the 497 document identification items. 499 All items end with a blank line. The reserved characters are ";", 500 "%", "=", ",", "#", LF, and CR. Reserved characters MUST be escaped. 501 The escape sequence is the same as described in [5]. 503 The service template is encoded in a UTF8 character set, but 504 submitted as a part of an internet-draft, which is encoded in ASCII 505 characters. All characters which are outside of the ASCII range MUST 506 be escaped using the % HEX HEX syntax. For example, the letter e 507 accent aigue would be represented as "%c3%a9". Unfortunately, this 508 will detract from the readability of the service template in the 509 internet draft. Hopefully some public domain tools will emerge for 510 translating escaped UTF8 characters into humanly readable ones. 512 Values in value lists are separated by commas. A value list is 513 terminated by a newline not preceded by a comma. If the newline is 514 preceded by a comma, the value list is interpreted to continue onto 515 the next line. 517 Attribute identifiers, attribute type names, and flags are all 518 case insensitive. For ease of presentation, upper and lower case 519 characters can be used to represent these in the template document. 520 Newlines are significant in the grammar. They delimit one item from 521 another, as well as separating parts of items internally. 523 String values are considered to be a sequence of non-whitespace 524 tokens potentially with embedded whitespace, separated from each 525 other by whitespace. Commas delimit lists of strings. String values 526 are trimmed so as to reduce any sequence of white space interior to a 527 string to a single white space. Preceding or trailing white space is 528 removed. For example: 530 " some value , another example " 532 is trimmed to 534 "some value" and "another example". 536 Note that there can be no ambiguity in string tokenization because 537 values in value lists are separated by a comma. String tokens are 538 not delimited by double quotes (") as is usually the case with 539 programming languages. 541 Attribute tags and values are useful for directory look-up. In this 542 case, decoding of character escapes and trimming white space MUST 543 be performed before string matching. In addition, string matching 544 SHOULD be case insensitive. 546 Templates obey the following ABNF [8] grammar: 548 template = tem-attrs attr-defs 549 tem-attrs = schemetype schemevers schemelang 550 schemetext schemeurl 551 schemetype = "type" "=" scheme termdef 552 schemevers = "version" "=" version-no termdef 553 schemelang = "language" "=" langtag termdef 554 schemetext = "description" "=" newline desc-text termdef 555 schemeurl = "url-syntax" "=" newline url-bnf termdef 556 url-bnf = *[ com-chars ] 557 ; An ABNF describing the production 558 ; in the service: URL grammar of Section 2.1. 559 scheme = service-type [ "." naming-auth ] 560 service-type = scheme-name 561 naming-auth = scheme-name 562 scheme-name = alpha [1*schemechar] [ "." 1*schemechar ] 563 schemechar = alpha / digit / "-" / "+" / 564 version-no = 1*digit "." 1*digit 565 langtag = 2*lower-alpha ;see [3] 566 desc-text = *[ com-chars ] 567 ; A block of free-form text for reading by 568 ; people describing the service in a short, 569 ; informative manner. 570 termdef = newline newline 571 attr-defs = *( attr-def / keydef ) 572 attr-def = id "=" attrtail 573 keydef = id "=" "keyword" newline [help-text] newline 574 attrtail = type flags newline [value-list] [help-text] 575 [value-list] newline 576 id = 1*attrchar 577 type = "string" / "integer" / "boolean" / "opaque" 578 flags = ["m"/"M"] ["l"/"L"] ["o"/"O"] ["x"/"X"] 579 value-list = value newline / value "," value-list / 580 value "," newline value-list 581 help-text = 1*( "#" help-line ) 582 ; A block of free-form text for reading by 583 ; people describing the attribute and 584 ; its values. 585 help-line = *[ com-chars ] newline 586 attrchar = schemechar / ":" / "_" / "$" / "~" / "@" / "." / 587 "|" / "<" / ">" / "*" / "&" 588 value = string / integer / boolean / opaque 589 string = safe-char *[safe-char / white-sp] safe-char 590 integer = [ "+" | "-" ] 1*digit 591 boolean = "true" / "false" 592 opaque = 1*digit ":" 4*radix64-char 593 ; The digits define the original length of 594 ; the opaque value. The restricted character 595 ; string is the radix-64 encoding of the 596 ; opaque value( [7], Sect. 6.8.) 597 ; Newlines are ignored in decoding radix-64 598 ; values. 599 com-chars = safe-char / white-sp / "," / ";"/ "%" 600 safe-char = attrchar / escaped / " " / "!" / '"' / "'" / 601 "|" / "(" / ")" / "+" / "-" / "." / ":" / 602 "=" / "?" / "[" / "]" / "{" / "/" / "{" / 603 "$" 604 ; All UTF8 printable characters are 605 ; included except ",", "%", ";", and "#". 606 escaped = "%" hex hex 607 hex = digit / "A" / "B" / "C" / "D" / "E" / 608 "a" / "b" / "c" / "d" / "e" 609 white-sp = space / tab 610 newline = CR / ( CR LF ) 612 3.2. Semantics of Service Type Templates 614 The service type template defines the service attributes and service: 615 URL syntax for a particular service type. The attribute definition 616 includes the attribute type, default values, allowed values and other 617 information. 619 3.2.1. Definition of a Service Template 621 There are six items included in the service template. The semantics 622 of each item is summarized below. 624 type The scheme name of the service scheme. The scheme name 625 consists of the service type name and an optional naming 626 authority name, separated from the service type name by a 627 period. See 3.2.2 for the conventions governing service 628 type names. 630 version The version number of the service type specification. 632 language The language of the service type specification. 634 description 635 A description of the service suitable for inclusion in 636 text read by people. 638 url-syntax 639 The syntax of the service type-specific URL part of the 640 service: URL. 642 attribute definitions 643 A collection of zero or more definitions for attributes 644 associated with the service in service registrations. 646 Each of the following subsections deals with one of these items. 648 3.2.2. Service Type 650 The service scheme consists of the service type name and an optional 651 naming authority name separated from the service type name by a 652 period. The service scheme is a string that is appended to the 653 'service:' URL scheme identifier, and is the value of the "type" 654 item in the template document. If the naming authority name is 655 absent it is assumed to be IANA. 657 3.2.3. Version Number 659 The version number of the service type template is the value of the 660 "version" item. A draft proposal starts at 0.0, and the minor number 661 increments once per revision. A standardized template starts at 1.0. 662 Additions of optional attributes add one to the minor number, and 663 additions of required attributes, changes of definition, or removal 664 of attributes add one to the major number. The intent is that an 665 old service template still accurately, if incompletely, defines the 666 attributes of a service registration if the template only differs 667 from the registration in its minor version. See Section 4 for more 668 detail on how to use the version attribute. 670 3.2.4. Service Type Language 672 The service type language is a RFC 1766 Language Tag defining the 673 language of the template [3] and is the value of the "language" item. 675 3.2.5. Description 677 The description is a block of text readable by people in the language 678 of the template and is the value of the "description" item. It 679 should be sufficient to identify the service to human readers and 680 provide a short, informative description of what the service does. 682 If the service type corresponds to a particular protocol, the 683 protocol specification must be cited here. The protocol need not be 684 a standardized protocol. The template might refer to a proprietary 685 specification, and refer the reader of the template to a contact 686 person for further information. 688 3.2.6. Syntax of the Service Type-specific URL Part 690 The syntax of the service type-specific part of the service: 691 URL is provided in the template document as the value of the 692 "url-syntax" item. The field of the service: URL is 693 designed to provide additional information to locate a service when 694 the field is not sufficient. The field 695 distinguishes URLs of a particular service type from those of another 696 service type. For instance, in the case of the lpr service type, the 697 must include the queue name [11], but other service types 698 may not require this information. 700 The syntax for the field MUST accompany the definition 701 of a new service type, unless the URL scheme has already been 702 standardized and is not a service: URL. The syntax is included in 703 the template document as an ABNF [8] following the rules for URL 704 syntax described in [5]. The field can be very simple, 705 or even omitted. If the URL scheme has already been standardized, 706 the "url-syntax" item SHOULD include a reference to the appropriate 707 standardization documents. Abstract service types may defer this 708 field to the template documents describing their concrete instances. 710 3.2.7. Attribute Definition 712 The bulk of the template is typically devoted to defining service 713 type-specific attributes. An attribute definition precisely 714 specifies the attribute's type, other restrictions on the attribute 715 (whether it is multi-valued, optional, etc), some text readable by 716 people describing the attribute, and lists of default and allowed 717 values. The only required information is the attribute's type, the 718 rest are optional. Registration, deregistration and the use of 719 attributes in queries can be accomplished using the Service Location 720 Protocol [12] or other means. 722 Attributes are used to convey information about a given service for 723 purposes of differentiating different services of the same type. 724 They convey information to be used in the selection of a particular 725 service to establish communicate with, either through a program 726 offering a human interface or programmatically. Attributes can be 727 encoded in different character sets and in different languages. The 728 procedure for doing this is described in Section 6. 730 An attribute definition begins with the specification of the 731 attribute's identifier and ends with a single empty line. Attributes 732 definitions have five components (in order of appearance in a 733 definition): 735 1. An attribute identifier (the name of the attribute), 737 2. Attribute descriptors (type and flags), 739 3. An optional list of values which are assigned to the attribute by 740 default, 742 4. An optional block of text readable by people providing a short, 743 informative description of the attribute, 745 5. An optional list of allowed values which restrict the value or 746 values the attribute can take on. 748 3.2.7.1. The Attribute Identifier 750 An attribute definition starts with the specification of the 751 attribute's identifier. The attribute's identifier serves as the 752 name of the attribute. Note that the characters used to compose an 753 attribute identifier are restricted to those characters considered 754 unrestricted for inclusion in a URL according to [5]. The reason 755 is that services can display prominent attributes in their service: 756 URL registrations. Each attribute identifier must be unique in the 757 template. Since identifiers are case folded, upper case and lower 758 case characters are the same. 760 3.2.7.2. The Attribute Type 762 Attributes can have one of five different types: string, signed 763 integer, boolean, opaque, or keyword. The attribute's type 764 specification is separated from the attribute's identifier by 765 an equal sign ("=") and follows the equal sign on the same line. 766 The string, signed integer, and boolean types have the standard 767 programming language or database semantics. Integers are restricted 768 to those signed values that can be represented in 32 bits. Booleans 769 are either TRUE or FALSE. Opaques are radix64 numbers [7] that can be 770 used to represent any other kind of data. Keywords are attributes 771 that have no characteristics other than their existence (and possibly 772 the descriptive text in their definition). 774 Keyword and boolean attributes impose restrictions on the following 775 parts of the attribute definition. Keyword attribute definitions 776 MUST have no flag information following the type definition, nor any 777 default or allowed values list. Boolean attributes are single value 778 only, i.e., multi-valued boolean attributes are not allowed. 780 3.2.7.3. Attribute Flags 782 Flags determine other characteristics of an attribute. With the 783 exception of keyword attributes, which may not have any flags, 784 flags follow the attribute type on the same line as the attribute 785 identifier, and are separated from each other by whitespace. Flags 786 may appear in any order after the attribute type. Other information 787 must not follow the flags, and only one flag identifier of a 788 particular flag type is allowed per attribute definition. 790 The semantics of the flags are as follows: 792 - o or O 794 Indicates that the attribute is optional. If this flag is 795 missing, the attribute is required in every service registration. 797 - m or M 799 Indicates that the attribute can take on multiple values. If 800 this flag is present, every value in a multi-valued attribute 801 has the same type as the type specified in the type part of the 802 attribute definition. Boolean attributes must not include this 803 flag. 805 - l or L 807 Indicates that attribute is literal, i.e., is not meant to be 808 translated into other languages. If this flag is present, the 809 attribute is not necessarily human-readable, and should not be 810 translated when the template is translated. See Section 6 for 811 more information about translation. 813 - x or X 815 Indicates that clients SHOULD include the indicated attribute 816 in requests for services. Neglecting to include this attribute 817 will not sufficiently differentiate the service. If services are 818 obtained without selecting this attribute they will quite likely 819 be useless to the client. 821 The values for multivalued attributes are an unordered set. 822 Deletions of individual values from a multivalued attribute are not 823 supported, and deletion of the attribute causes the entire set of 824 values to be removed. 826 3.2.7.4. Default Value or List 828 If the attribute definition includes a default value or, in the 829 case of multivalued attributes, a default values list, it begins on 830 the second line of the attribute definition and continues over the 831 following lines until a line ends without a comma. Newlines cannot 832 be embedded in values unless escaped. See Section 2.1. 834 Particular attribute types and definitions restrict the default 835 values list. Keyword attributes MUST NOT have a list of defaults. 836 If an optional attribute's definition has an allowed values list, 837 then a default value or list is REQUIRED. The motivation for this 838 is that defining an attribute with an allowed values list is meant 839 to restrict the values the attribute can take on, and requiring a 840 default value or list assures that the default value is a member of 841 the given set of allowed values. 843 The default value or list indicates what values the attribute is 844 given if no values are assigned to the attribute when a service 845 is registered. If an optional attribute's definition includes no 846 default value or list, the following defaults are assigned: 848 1. String values are assigned the empty string, 850 2. Integer values are assigned zero, 852 3. Boolean values are assigned false, 853 4. Opaque values are assigned a byte array containing no values, 855 5. Multi-valued attributes are initialized with a single value. 857 For purposes of translating nonliteral attributes, the default values 858 list is taken to be an ordered set, and translations MUST maintain 859 that order. 861 3.2.7.5. Descriptive Text 863 Immediately after the default values list, if any, a block of 864 descriptive text SHOULD be included in the attribute definition. 865 This text is meant to be readable by people, and should include 866 a short, informative description of the attribute. It may also 867 provide additional information, such as a description of the allowed 868 values. This text is primarily designed for display by interactive 869 browsing tools. The descriptive text is set off from the surrounding 870 definition by a crosshatch character ("#") at the beginning of 871 the line. The text should not, however, be treated as a comment 872 by parsing and other tools, since it is an integral part of the 873 attribute definition. Within the block of descriptive text, the text 874 is transferred verbatim, including indentation and line breaks, so 875 any formatting is preserved. 877 3.2.7.6. Allowed Values List 879 Finally, the attribute definition concludes with an optional 880 allowed values list. The allowed values list, if any, follows the 881 descriptive text, or, if the descriptive text is absent, the initial 882 values list. The syntax of the allowed values list is identical to 883 that of the initial values list. The allowed values list is also 884 terminated by a line that does not end in a comma. If the allowed 885 values list is present, assignment to attributes is restricted to 886 members of the list. 888 As with the default values list, the allowed values list is also 889 considered to be an ordered set for purposes of translation. 891 3.2.7.7. Conclusion of An Attribute Definition 893 An attribute definition concludes with a single empty line. 895 4. A Process For Standardizing New Service Types 897 New service types can be suggested simply by providing a service type 898 template and a short description about how to use the service. The 899 template MUST have its "version" template attribute set to 0.0. 901 MAJOR revision numbers come before the '.', MINOR revision numbers 902 come after the '.'. 904 The minor version number increments once with each change until it 905 achieves 1.0. There is no guarantee any version of the service 906 template is backward compatible before it reaches 1.0. 908 Once a service template has reached 1.0, the definition is "frozen" 909 for that version. New templates must be defined, of course, to 910 refine that definition, but the following rules must be followed: 912 A MINOR revision number signifies the introduction of a compatible 913 change. A MAJOR revision number signifies the introduction of an 914 incompatible change. This is formalized by the following rules: 916 - Any new optional attribute defined for the template increases 917 the minor version number by one. All other attributes for the 918 version must continue to be supported as before. A client which 919 supports 1.x can still use later versions 1.y (where x "." "." 982 Each of these fields are defined in Section 2. They correspond 983 to the values of the template fields "type", "version" and 984 "lang". The files for the example templates in this 985 document are called "foo.0.0.en", "Net-Transducer.0.0.en" and 986 "Net-Transducer:Thermomoter.0.0.en". See Section A. 988 The reviewer will ensure that the template submission to IANA has the 989 correct version number in the "version" and "lang" fields. 991 No service type template will be accepted for inclusion in the 992 service template registry unless the Internet Draft submitted 993 includes a security considerations section and contact information 994 for the template document author. 996 The IANA will maintain a registry containing both the service type 997 templates, and the template description document containing the 998 service type template, including all previous versions. The IANA 999 will receive notice by email from the reviewers, which will contain a 1000 reference to the Internet Draft that contains the service template. 1001 This Internet Draft will be edited to remove the Internet Draft 1002 headers and replace them with a simple header stating "This document 1003 contains a Service Type Template." 1005 Neither the reviewer nor the IANA will take any position on claims of 1006 copyright or trademark issues with regard to templates. 1008 6. Internationalization Considerations 1010 The service: URL must be encoded using the rules set forth in [5]. 1011 The character set encoding is limited to specific ranges within the 1012 US-ASCII character set [4]. 1014 The template is encoded in UTF8 characters. 1016 The template must not include any characters outside of the US-ASCII 1017 printable range unless these values are escaped. For instance, a 1018 template in Greek would encode the lower case alpha as "which is the 1019 UTF8 encoding of the Unicode value 0x03b1. Non-US-ASCII characters 1020 in templates will NOT be human readable until un-escaped. 1022 6.1. Language Identification and Translation 1024 The language used in attribute strings should be identified using the 1025 "language" template item as defined by [3]. 1027 A program can translate a service registration from one language to 1028 another provided it has both the template of the language for the 1029 registration and the template of the desired target language. All 1030 standardized attributes are in the same order in both templates, 1031 allowing one template to be used as a 'look up table' into the other. 1032 A string in one language can be translated to another by finding the 1033 string in the corresponding position in the both templates. 1035 If a template in a desired language is not available, a "best-effort" 1036 translation can always be made from an existing template. 1038 Non-literal attribute definitions, attribute identifiers, attribute 1039 type names, attribute flags, and the boolean constants "true" 1040 and "false" are never translated. Translation of attribute 1041 identifiers is prohibited because, as with domain names, they can 1042 potentially be part of a service: URL and therefore their character 1043 set is restricted. In addition, as with variable identifiers in 1044 programming languages, they could become embedded into program code. 1045 Other strings, including the descriptive help text, are directly 1046 translatable from one language to another. 1048 When the service type is standardized, more than one document can 1049 be submitted for review. One service type description is approved 1050 as a master, so that when a service type template is updated in one 1051 language, all the translations (at least eventually) reflect the same 1052 semantics. If no document exists describing the standard translation 1053 of the service type, a 'best effort' translation for strings should 1054 be done. 1056 7. Security Considerations 1058 Service type templates provide information that is used to interpret 1059 information obtained by the Service Location Protocol. If these 1060 templates are modified or false templates are distributed, services 1061 may not correctly register themselves, or clients might not be able 1062 to interpret service information. 1064 The service: URLs themselves MAY specify the service access point 1065 and protocol for a particular service type. The Service Location 1066 Protocol [12] distributes service: URLs and has an authentication 1067 mechanism that allows service: URLs of registered services to be 1068 signed and for the signatures to be verified by clients. 1070 Each Service Template will include a security considerations section 1071 which will describe security issues with using the service scheme for 1072 the specific Service Type. 1074 A. Service Template Examples 1076 The text in the template example sections is to be taken as being a 1077 single file. They are completely fictitious (ie. the examples do 1078 not represent real services). 1080 The FOO example shows how to use service templates for an application 1081 that has very few attributes. Clients request the FOO server where 1082 their user data is located by including their user name as the value 1083 of the user attribute. 1085 The Net-Transducer example shows how abstract service types are 1086 defined and how a corresponding concrete instance is defined. A 1087 system might support any of several NetTransducer services. Here we 1088 give only one concrete instance of the abstract type. 1090 It is not necessary to register concrete templates for an abstract 1091 service type if the abstract service type template is completely 1092 clear as to what possible values can be used as a concrete type, and 1093 what their interpretation is. 1095 A.1. FOO 1097 -------------------------template begins here----------------------- 1098 type=FOO 1100 version=0.0 1102 lang=en 1104 description= 1105 The FOO service URL provides the location of an FOO service. 1107 url-syntax= 1108 url-path= ; There is no URL path defined for a FOO URL. 1110 users= string M L O 1111 # The list of all users which the FOO server supports. 1113 groups= string M L O 1114 # The list of all groups which the FOO server supports. 1115 --------------------------template ends here------------------------ 1117 The Internet Draft describing the FOO scheme template must indicate 1118 contact information and security considerations, e.g., 1120 contact="Erik Guttman" 1122 security considerations= 1123 If the USER and GROUPS attributes are included a 1124 possibility exists that the list of identities for users or groups 1125 can be discovered. This information would otherwise be difficult 1126 to discover. 1128 A.2. Abstract Service Type: Net-Transducer 1130 The Internet Draft for the service type template contains the 1131 following text: 1133 -------------------------template begins here----------------------- 1134 type=Net-Transducer 1136 version=0.0 1138 lang=en 1140 description= 1141 This is an abstract service type. The purpose of the Net- 1142 Transducer service type is to organize into a single category 1143 all network enabled Transducers which have certain properties. 1145 url-syntax= 1146 url-path= ; Depends on the concrete service type. 1147 ; See these templates. 1149 sample-units= string L 1150 # The units of sample that the Transducer provides, for instance 1151 # C (degrees Celsius), V (Volts), kg (Kilograms), etc. 1153 sample-resolution= string L 1154 # The resolution of the Transducer. For instance, 10^-3 means 1155 # that the Transducer has resolution to 0.001 unit. 1157 sample-rate= integer L 1158 # The speed at which samples are obtained per second. For 1159 # instance 1000 means that one sample is obtained every millisecond. 1161 --------------------------template ends here------------------------ 1163 In addition, the following format might be used for the needed 1164 contact and security considerations information. 1165 .......... 1167 contact="Erik Guttman" 1169 security considerations= 1170 See the security considerations of the concrete service types. 1172 A.3. Concrete Service Type: Net-Transducer:Thermometer 1174 -------------------------template begins here----------------------- 1175 type=service:Net-Transducer:Thermometer 1177 version=0.0 1179 lang=en 1180 description= 1181 The Thermometer is a Net-Transducer capable of reading temperature. 1182 The data is read by opening a TCP connection to one of the ports 1183 in the service URL and reading an ASCII string until an NULL 1184 character is encountered. The client may continue reading data at 1185 no faster than the sample-rate, or close the connection. 1187 url-syntax= 1188 url-path = ; ports 1189 port-list = ";ports=" port-list 1190 ports = port / port "," ports 1191 ; See the Service URL production rule. 1192 ; These are the ports connections can be made on. 1194 location-description=string 1195 # The location where the Thermometer is located. 1197 operator=string O 1198 # The operator to contact to have the Thermometer serviced. 1200 --------------------------template ends here------------------------ 1202 ......... 1204 contact="Erik Guttman" 1206 security considerations= 1207 There is no authentication of the Transducer output. Thus, 1208 the Thermometer output could easily be spoofed. 1210 A.4. service: URLs and SLP 1212 A user with an FOO enabled calendar application should not be 1213 bothered with knowing the address of their FOO server. The 1214 calendar client program can use SLP to obtain the FOO service: URL 1215 automatically, say 'service:foo://server1.nosuch.org', by issuing 1216 a Service Request. In the event that this FOO server failed, the 1217 Calendar client can issue the same service request again to find the 1218 backup FOO server, say 'service:foo://server2.nosuch.org'. In both 1219 cases, the service: URL conforms to the FOO service template as do 1220 the associated attributes (user and group.) 1222 A network thermometer could be advertised as: 1224 URL = service:net-transducer:thermometer://v33.test/ports=3211 1225 Attributes = (location-description=Missile bay 32), 1226 (operator=Joe Agent), (sample-units=C), 1227 (sample-resolution=10^-1),(sample-rate=10) 1229 This might be very useful for a technician who wanted to find a 1230 Thermometer in Missile bay 32, for example. 1232 B. Full Copyright Statement 1234 Copyright (C) The Internet Society (1997). All Rights Reserved. 1236 This document and translations of it may be copied and furnished to 1237 others, and derivative works that comment on or otherwise explain it 1238 or assist in its implmentation may be prepared, copied, published 1239 and distributed, in whole or in part, without restriction of any 1240 kind, provided that the above copyright notice and this paragraph 1241 are included on all such copies and derivative works. However, 1242 this document itself may not be modified in any way, such as by 1243 removing the copyright notice or references to the Internet Society 1244 or other Internet organizations, except as needed for the purpose 1245 of developing Internet standards in which case the procedures 1246 for copyrights defined in the Internet Standards process must be 1247 followed, or as required to translate it into languages other than 1248 English. 1250 The limited permissions granted above are perpetual and will not be 1251 revoked by the Internet Society or its successors or assigns. 1253 This document and the information contained herein is provided on an 1254 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1255 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1256 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1257 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1258 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1260 C. Acknowledgments 1262 Ryan Moats suggestions were very useful in producing this document. 1264 References 1266 [1] Protocol and service names, October 1994. 1267 ftp://ftp.isi.edu/in-notes/iana/assignments/service-names. 1269 [2] Port numbers, July 1997. 1270 ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers. 1272 [3] H. Alvestrand. Tags for the Identification of Languages. RFC 1273 1766, March 1995. 1275 [4] ANSI. Coded Character Set -- 7-bit American Standard code for 1276 Information Interchange. X3.4-1986, 1986. 1278 [5] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource 1279 Locators (URL): Generic Syntax and Semantics. RFC1738 as 1280 amended by RFC1808 and updated by draft-fielding-url-syntax-05.txt, 1281 May 1997. (work in progress). 1283 [6] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource 1284 Locators (URL). RFC 1738, December 1994. 1286 [7] N. Borenstein and N. Freed. Multipurpose Internet Mail 1287 Extensions (MIME) Part One: Format of Internet Message Bodies. 1288 RFC 2045, November 1996. 1290 [8] D. Crocker and P. Overell. Augmented BNF for Syntax 1291 Specifications: ABNF. draft-ietf-drums-abnf-04.txt, September 1292 1997. (work in progress). 1294 [9] J. Myers. Simple Authentication and Security Layer (SASL). 1295 draft-myers-auth-sasl-11.txt, May 1997. (work in progress). 1297 [10] J. G. Myers. ACAP -- Application Configuration Access Prototol. 1298 draft-ietf-acap-spec-04.txt, June 1997. (work in progress). 1300 [11] Pete St. Pierre. Definition of lpr: URLs for use with Service 1301 Location. draft-ietf-svrloc-lpr-scheme-00.txt, July 1997. 1302 (work in progress). 1304 [12] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 1305 Location Protocol. RFC 2165, July 1997. 1307 [13] F. Yergeau. UTF-8, a transformation format of unicode and ISO 1308 10646. RFC 2044, October 1996. 1310 Authors' Addresses 1312 Questions about this memo can be directed to: 1314 Erik Guttman Charles E. Perkins James Kempf 1315 Sun Microsystems Sun Microsystems Sun Microsystems 1316 Bahnstr. 2 901 San Antonio Rd. 901 San Antonio Rd. 1317 74915 Waibstadt Palo Alto, CA, 94303 Palo Alto, CA, 94303 1318 Germany USA USA 1319 +49 7263 911484 1 650 786 6464 1 650 786 5890 1320 1 650 786 6445 (fax) 1 650 786 6445 (fax) 1321 erik.guttman@sun.com charles.perkins@sun.com james.kempf@sun.com