idnits 2.17.1 draft-ietf-svrloc-service-scheme-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 8) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 105: '...information which follows it MUST obey...' RFC 2119 keyword, line 185: '...ach service: URL SHOULD be accompanied...' RFC 2119 keyword, line 381: '... ; The integer MUST fall within the ...' RFC 2119 keyword, line 422: '... String matching MUST be done after ch...' RFC 2119 keyword, line 424: '... SHOULD be case insensitive....' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 410 has weird spacing: '..." some name ...' == Line 414 has weird spacing: '... "some name"...' -- 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. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'ABNF' on line 1309 looks like a reference -- Missing reference section? 'RFC1738' on line 1340 looks like a reference -- Missing reference section? 'RFC 1738' on line 134 looks like a reference -- Missing reference section? 'SLP' on line 1350 looks like a reference -- Missing reference section? 'FINDING' on line 1318 looks like a reference -- Missing reference section? '-' on line 380 looks like a reference -- Missing reference section? 'RFC 1521' on line 398 looks like a reference -- Missing reference section? 'ASCII' on line 1312 looks like a reference -- Missing reference section? 'RFC2055' on line 1325 looks like a reference -- Missing reference section? 'RFC2054' on line 1328 looks like a reference -- Missing reference section? 'NFSURL' on line 1322 looks like a reference -- Missing reference section? 'RFC1179' on line 1347 looks like a reference -- Missing reference section? 'RFC1759' on line 1334 looks like a reference -- Missing reference section? 'RFC1936' on line 1171 looks like a reference -- Missing reference section? 'CHAR-REG' on line 1315 looks like a reference -- Missing reference section? 'RFC1766' on line 1337 looks like a reference -- Missing reference section? 'RFC1939' on line 1331 looks like a reference -- Missing reference section? 'RFC1734' on line 1344 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Location Working Group Erik Guttman 3 Internet Draft Sun Microsystems, Inc. 4 Expires in six months 6 The service: URL Scheme 7 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its 11 areas, and its working groups. Note that other groups may also 12 distribute working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other 16 documents at any time. It is inappropriate to use Internet- 17 Drafts as reference material or to cite them other than as 18 ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check 21 the ``1id-abstracts.txt'' listing contained in the Internet- 22 Drafts Shadow Directories on ftp.is.co.za (Africa), 23 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 24 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 26 Abstract 28 The service: URL scheme is used to provide service access information 29 for arbitrary network services. These URLs provide an extensible 30 framework for client based network software to obtain configuration 31 information required to make use of network services. A service: URL 32 may be accompanied by a set of well defined attributes which define 33 the characteristics of the service. These attributes may convey 34 protocol configuration information to client software or service 35 characteristics meaningful to end users. This document describes how 36 to define and standardize new service types and attributes for use 37 with the service: scheme and provides examples. 39 Table of Contents 41 1. Introduction 42 1.1. The service: Scheme 43 1.2. Related work 44 2. Use of service: URLs 45 3. Specifying A New Service Type 46 3.1. A Service Type specification defines: 47 3.1.1. Service Type 48 3.1.2. The service: 'urlpath' information 49 3.1.3. Attributes 50 3.1.4. Service Discovery Multicast Address 51 3.2. Specifying Attributes 52 3.2.1. A subtlety 53 3.2.2. Types and String Encoding 54 3.2.3. Attributes with multiple values 55 3.2.4. Grouping attributes values together in records 56 3.3. Special Attributes 57 3.3.1. Service Discovery Multicast Address 58 3.3.2. version 59 3.3.3. Language tag 60 3.4. Service Type templates 61 3.4.1. Definition 62 3.4.2. Manditory Attributes 63 3.4.3. Attribute syntax for Service Type templates 64 3.4.4. Use of templates by the Service Location Protocol 65 4. A Process For Standardizing New Service Types 66 5. Encoding Rules for Service Type URLs 67 6. Examples 68 6.1. NFS 69 6.1.1. The NFS Service Type template 70 6.1.2. Example: A 'pub' directory 71 6.1.3. Example: A 'dist' directory 72 6.2. LPR 73 6.3. POP3 74 7. Security Considerations 75 8. Internationalization Considerations 76 8.1. Character Set identification and use 77 8.2. Language identification and translation 78 9. Bibliography 79 10. Author's Address 81 1. Introduction 83 This document describes a URL scheme which will allow arbitrary 84 network services to have a standard notation for defining their 85 service access point. 87 In addition it describes how to define a set of attributes to 88 associate with service: URLs. These attributes will allow end users 89 and programs to select between network services of the same type that 90 have different capabilities. 92 The use of these attributes is recommended but not required to make 93 use of the service: URL. The minimal encoding rules for attributes 94 are specified. 96 Service Type templates are used to describe services which use the 97 service: URL in a standard way. The rules for writing such a 98 template are provided, as are three examples. 100 All grammar encoding follows the Augmented BNF for syntax 101 specifications [ABNF] with a few deviations. 103 1.1. The service: Scheme 105 The service: scheme and all information which follows it MUST obey 106 the URL conventions defined in [RFC1738]. 108 The scheme specific information following the service: scheme 109 provides the service type and address of a network service. It may 110 additionally include service type specific information. The form of 111 a service: URL is as follows: 113 serviceurl = "service:" service-type ":" service-part 115 The formal syntax for a serviceurl is given in Section 5. 117 The service-type string indicates a specific protocol, such that 118 client software can be expected to unambiguously make use of the 119 service. The Service Type determines semantics of the service-part 120 and the attributes associated with the service: URL. 122 The service-part includes an ip-schemepart. This will define either 123 a domain name or a numerical ip address for the service and possibly 124 more, such as a port number to use. The remainder of the service- 125 part is intended to provide sufficient information for client 126 software to be able to bind and make use of a service. 128 The service-part allows for extensions to the basic tuple of Service 129 Type and host (and possibly port number), so that more information 130 may be provided to uniquely identify the resource. It is also 131 possible, though less preferable, to provide uniquely identifying 132 information in the attribute information associated with a service: 133 URL. This string will be referred to in this document as the 134 'urlpath' to be consistent with [RFC 1738]. 136 The attributes associated with the URL are not included in the URL. 137 They are stored and retrieved using other mechanisms. The service: 138 URL serves as a unique identifier, to be used in registering or 139 requesting the attribute information. The Service Location Protocol 140 [SLP] specifies how such information may be advertised by network 141 services and obtained by client software. Other facilities, such as 142 Directory Services, could be used to distribute this information. 144 Attributes are associated with service: URLs for three reasons: 146 1. They allow configuration of the client. Many servers have 147 optional features. Clients which require or prefer to make 148 use of these features can proceed to do so without protocol 149 negotiation or feature selection. Client configuration 150 parameters or server convention information may be obtained. 152 2. Client software may have particular requirements. The 153 attributes associated with a given URL allow for automatic 154 selection of services which have certain features. For 155 example, client software may require a server which has 156 a particular version or which has access to specific 157 resources. 159 3. Attributes support end user selection by characteristic 160 as opposed to simply by type. These attributes may be 161 used to populate service browsing and choosing user 162 interfaces, for example. 164 1.2. Related work 166 The "Finding Stuff" work by Ryan Moats and Martin Hamilton uses 167 service: URLs provide access information about arbitrary network 168 protocols through DNS. [FINDING] They do not associate service 169 attributes with these URLs. The URLs allow them to provide 170 nonstandard service port information and to relate several protocols 171 to single abstract services, such as white pages and yellow pages. 173 2. Use of service: URLs 175 The service: URL is intended to allow arbitrary client server and 176 peer to peer systems to make use of a standardized dynamic service 177 access point discovery mechanism. 179 It is intended that service: URLs be obtained with their associated 180 attributes. In this way a client application may obtain the URLs of 181 several services of the same type and distinguish the most preferable 182 among them by means of their attributes. 184 These attributes will take the form specified by the "service- 185 template", described below. Each service: URL SHOULD be accompanied 186 by all attributes in the template (except the template specific 187 special attributes.) The registration of this attribute information 188 could be done using various mechanisms, one of which is the Service 189 Location Protocol [SLP]. 191 The client will use the service: URL to bind directly to a service. 192 The client must have a priori knowledge of how to use the network 193 protocol associated with the Service Type included in the service: 194 URL. 196 3. Specifying A New Service Type 198 A Service Type should be specified to be a close as possible to a 199 particular protocol. It may be tempting to create a Service Type for 200 a 'class of services', such as 'printer'. This will complicate the 201 specification later on, as the single service type must be 202 differentiated between the different protocols at the level of 203 service specific information or attributes. 205 It is much clearer if the protocol is simply named by a service type. 206 The urlpath is normally used to supply additional naming information 207 to uniquely identify the service. The attribute information can then 208 be used to indicate configuration details, optional features 209 available and characteristics (which may be relevant to a human user 210 or to a program.) 212 3.1. A Service Type specification defines: 214 3.1.1. Service Type 216 This is a string which will be prepended by the 'service:' scheme. 217 It may be a name which is entirely invented or be the same as a well 218 known service scheme. For example, service:http: might refer to a 219 HTTP server, whereas the http: scheme used in a URL generally refers 220 to a document. 222 The meaning of this service type must be fully described by service 223 type specification. 225 A network protocol specification should be cited as the definitive 226 reference for the protocol to use when binding to the service access 227 point provided by the service: URL. 229 3.1.2. The service: 'urlpath' information 231 This information is included in the URL in order to provide uniquely 232 identifying information. This mechanism is used in the examples 233 which follow in order to identify a mountable filesystem (using the 234 'nfs' service type) and an lpr print queue (using the 'lpr' service 235 type). 237 The syntax and interpretation of the urlpath must accompany the 238 definition of a new Service Type. The 'default' urlpath definition 239 is that it is entirely omitted except possibly a terminating slash. 240 The syntax is: 242 urlpath = [ "/" ] 244 Every effort to remain consistent with the syntax forms and styles of 245 other standardized urlpaths should be pursued. See [RFC1738] for 246 examples and guidance. 248 3.1.3. Attributes 250 This information provides information about the service's 251 capabilities, characteristics and required client configuration. 252 Each attribute which is defined must have a default value and 253 definition of all values it can take. 255 An attribute normally takes only one value, but optionally it may be 256 defined to be able to take multiple values. 258 The transmission of attributes is not described by this document. 259 Attribute registration, deregistration and the use of attributes in 260 queries may be accomplished using a number of different protocols. A 261 future document (or possibly a later version of this document) will 262 describe how to encode attributes for use with different services. 263 The Service Location Protocol [SLP] defines one method of encoding 264 attributes. 266 3.1.4. Service Discovery Multicast Address 268 Service Types may be registered with IANA and obtain a unique Service 269 Discovery Multicast Address. This address is to be used with the 270 Service Location Protocol [SLP] as a means to specifically discover a 271 single type of service in a network without burdening all other 272 servers. 274 This is purely optional: Services which use the service: scheme do 275 not need to have a unique Service Discovery Multicast Address 276 assigned to them. 278 3.2. Specifying Attributes 279 Attributes are used to convey information about a given service for 280 purposes of differentiating different services of the same type. 281 They convey information to be used in the selection of which service 282 to bind to, either for human consumption or for use by a program. 284 Attributes may be encoded in different character sets and in 285 different languages. The procedure for doing this is described in 286 Section 8.0. 288 Attributes have two components. The first is a 'tag'. This is a 289 string with certain encoding rules. The second component is a set of 290 values. The set of values may be NULL, in which case the attribute 291 is a 'keyword'. The value or values of an attribute are typed, and 292 must have the same type for each value if the attribute is 293 multivalued. The rules for typing and encoding of attribute values 294 is given in the rest of Section 3.1. 296 3.2.1. A subtlety 298 There is a subtlety in the definition of attributes. A service 299 may support 'feature A' and 'feature B'. It may also have 300 'enhancement C'. Suppose the enhancement is only available 301 when feature B is used, in this case. If 'feature' is one 302 attribute and 'enhancement' is a second attribute, we can 303 describe the service with the following: 305 feature = A, B 306 enhancement = C 308 It will be impossible to tell if there is any dependency between 309 having feature B and enhancement C. Since the data relationships are 310 flat in the attribute encodings, it is necessary to explicitely state 311 all combinations as distinct values. This can be done in two ways. 312 Either all combinations of features which may have dependencies must 313 be given a well defined value or a 'record' format for an attribute 314 value must be used. 316 The combination method is only useful when there are very few values 317 to be combined, as it will quickly become a very large set of values 318 to define. In the case of the example we can define feature's values 319 as: 321 feature can take: 323 "A" | "A enhanced by C" | "B" | "B enhanced by C" 325 In our example: 327 feature = "A" , "B enhanced by C" 329 The suggested method for solving this problem with the 'record 330 format' is described in Section 3.2.4. below. 332 3.2.2. Types and String Encoding 334 Characters have been reserved in the specification of attributes in 335 order to avoid ambiguity with respect to the delimiters in the string 336 based protocol used in attribute lists. Further limitations may be 337 imposed if the attributes are to be encoded using another protocol. 339 The Service Location Protocol [SLP], for example, has several 340 reserved characters that are not to be used in attributes. SLP 341 provides an escape sequence to allow these characters to be used in 342 attribute values (not attribute tags.) The same character escape 343 mechanism is proposed here. 345 esc-char = "&" "#" 1*DIGIT ";" 347 The escaped character is replaced by a character sequence with no 348 spaces. The digits are a decimal representation of the character 349 value to be replaced, in the character set used for the attribute 350 encoding. 352 There are only three heavy handed syntactic devices used: 354 1. Blank lines are used to separate attributes. To add a 355 blank line to text, one would have to escape the CRLF 356 with 358 2. Commas are used to separate attribute values. To use a 359 comma in attribute encodings, escape the comma with , 361 3. Sets of colons are used to mark a default value (see 362 Section 3.4.3.) This means the string "::" must be 363 escaped in attribute values to :: 365 Attributes have the following grammar: 367 attribute = keyword / tag "=" 1#value CRLF CRLF 369 safe-chars = 370 white-sp = SPACE / CR / LF / TAB 371 key-chars = 374 tag = 1*safe-chars 375 keyword = 1*key-chars 376 value = string / integer / boolean / opaque 378 string = 1*safe-chars 380 integer = [-] 1*DIGIT 381 ; The integer MUST fall within the range of 382 ; values a 32 bit integer may take, ie. 383 ; "-2147483648" to "2147483647". 385 boolean = "TRUE" / "FALSE" 386 ; These values are the only exception to the 387 ; Internationalization rules in Section 8.0. 388 ; Independent of the translation of the 389 ; attributes, the boolean values remain the 390 ; indicated strings. 392 rad64-char = ALPHA / DIGIT / "+" / "-" / white-sp 394 opaque = 1*DIGIT ":" 4*rad64-char 395 ; The digits define the original length of the 396 ; opaque value. The restricted character string 397 ; is the radix-64 encoding of the opaque value. 398 ; See [RFC 1521], Section 5.2. 400 ; NOTE: White space is ignored in decoding 401 ; radix-64 values. 403 Note on the use of white space: 405 A string is considered to be a token in the case of a tag or 406 value. In this case, the string is 'trimmed'. White space interior 407 to a string token is left alone, while white space between the tokens 408 is removed. For example: 410 " some name = some value , another example " 412 would be trimmed to 414 "some name" '=' "some value" and "another example". 416 Note on string matching: 418 Attribute tags and values may be used by some protocols for directory 419 look-up. In this case, the following rules should be applied for 420 string matching of attribute strings. 422 String matching MUST be done after character escape encoding has been 423 removed, white space has been trimmed. In addition, string matching 424 SHOULD be case insensitive. 426 3.2.3. Attributes with multiple values 428 Attributes with multiple values must be defined so that the type of 429 each value is the same. Attributes with a boolean value may not take 430 multiple values. 432 3.2.4. Grouping attribute values together in records 434 In order to make use of this value encoding strategy, the record 435 format must be explicitely described. A 'delimiter' is used to 436 separate the fields in the record, a 'tab' is suggested, but others 437 are possible. 439 Each field in the attribute 'record' value must be defined 440 separately, as though it were an attribute value of its own. This 441 means it needs to have a type, default value, whether it can have 442 multiple values and a definition for all values it can take. If a 443 field is omitted, it is assumed to take its default value. It is 444 wise to have the default value be "NONE" or "NOT APPLICABLE", to make 445 it possible to explicitely declare only the relevent field values and 446 ignore the others. It is also possible to declare that the field has 447 no default value, if it MUST be defined in each record. 449 Following the example in Section 3.1, we can define the attribute 450 "feature" to have a record structure, delimited by tabs. Both fields 451 are single valued strings. The first field is the "feature name", 452 and has no default value. The second field is the "enhancement 453 name", with "NO ENHANCEMENT" as the default value. The resulting 454 value would be: 456 "feature =" "A" TAB "," "B" TAB "C" 458 The string "feature =" indicates the attribute 'feature' takes the 459 value to the right of the equals sign. The quotes will be used to 460 indicate that this is not an ABNF syntax but rather a string encoding 461 resulting from rules given elsewhere. (In this case the rules were 462 given in Section 3.1.1.). 464 The feature "A" has no second field value, the first value record is 465 A with NO ENHANCEMENT. The second value record that feature may take 466 is B with the enhancement C. 468 3.3. Special attributes 470 3.3.1. Service Discovery Multicast Address 471 This attribute is always included in Service Type templates. 473 It takes a single valued which takes a numerical IP address 474 specification. This should take the value of the assigned Service 475 Discovery Multicast Address. If the service has not been assigned 476 one, this attribute should take the value NONE. The value that this 477 attribute takes is defined by the following syntax: 479 discovery-addr = ipv4-addrport / ipv6-addrport / "NONE" 481 byte = 1*3DIGIT 482 ; This value MUST be between 0..255 483 ipv4-addrport = byte "." byte "." byte "." byte [":" 1*DIGIT] 485 hex = DIGIT / "A" / "B" / "C" / "D" / "E" / 486 "a" / "b" / "c" / "d" / "e" 487 ipv6-addrport = 32hex [":" 1*DIGIT] 489 The address must be a valid multicast address (according to either 490 IPv4 or IPv6 addressing rules. The port number identifies the port 491 number for the service discovery protocol. The Service Location 492 Protocol [SLP] uses port 427, which is the default if no port number 493 is given. 495 3.3.2. Version 497 This attribute has a string value of the form: 499 version = 1*DIGIT '.' 1*DIGIT 501 This is the version of the Service Type template. 503 This attribute MUST be included in every collection of attributes so 504 as to identify which version of the template it used to determine the 505 set of attributes and attribute definitions. Client software can use 506 these version numbers potentially to support old attributes, allowing 507 a smooth migration to new template definitions. 509 A Service Type template proposal starts at 0.0, and the minor number 510 increments once per revision. 512 A standardized template starts at 1.0. Additions of attributes add 513 one to the minor number, where changes of definition or removal of 514 attributes or values adds one to the major number. See Section 4 for 515 more detail on how to use the Version attribute. 517 3.3.3. Language tag 518 The Language tag attribute must be included with each template and 519 with each set of attributes associated with a particular service: 520 URL. This allows client applications to identify if the attributes 521 which will be comprehensible for a given user and retrieve them. See 522 8.2. 524 3.4. Service Type templates 526 3.4.1. Definition 528 The Service Type for the Service Type template is "service-template". 529 The service type specific information which follows is the location 530 and path information of a hypertext document which describes the 531 Service Type template, which is to be accessed using http. 533 For example, this template would be encoded as: 535 538 The document would be accessed by using: 540 543 3.4.2. Mandatory Attributes 545 The service-template Service Type has 3 mandatory attributes. The 546 template must also support the two special attributes version and 547 Service Discovery Multicast Address, as defined in Section 3.3. 548 These attributes are NOT specified in attributes which accompany 549 service: URLs. These attributes are only to be specified in Service 550 Type templates. 552 service type 554 The value of this attribute is a service type string. 556 Service Discovery Multicast Address 558 See section 3.3.1. 560 description 562 The service type is described here. This is a paragraph or 563 so of text which describes how to interpret the service: URL 564 for this particular service type. It should be clear what 565 protocol or protocols can bind to the service access point 566 which the service: URL resolves to. 568 Of these attributes tags, only "description" may be translated into 569 another language (see Section 8.0.) 571 3.4.3. Attribute syntax for Service Type templates 573 For each attribute the service type supports, an additional attribute 574 is added to the service type template. This attribute has the same 575 tag as the service type's attribute. The value of the attribute has 576 the following syntax: 578 tmpl-attr = attr-tag attr-val 580 safe-char = Any character other than "," and ":" 581 attr-tag = 1*[safe-char] 582 attr-val = [type] [m] [l] "::" default "::" description 584 type = ["STRING" | "BOOLEAN" | "INTEGER" | "OPAQUE"] 585 default = 1*[safe-char] 586 description = 1*[safe-char] 587 m = SPACE "M" 588 l = SPACE "L" 590 The default is "STRING" if type is omitted. 592 "M" indicates the attribute can have multiple values. If this 593 field is omitted it is assumed the attribute can have only 594 one value. 596 "L" indicates the attribute and its values must be considered 597 literally, that is, they must not be translated to other 598 languages. (See Section 8). 600 The default field provides the default value for the attribute. 602 The description field should be a paragraph of text describing the 603 attribute and the all the values it can take on. This information 604 will be used by those who develop user interfaces to display service 605 information and those who advertise services using attributes 606 associated with the service: URL. 608 3.4.4. Use of templates by the Service Location Protocol 610 Service templates may be used by the Service Location Protocol [SLP] 611 in three important ways: 613 First, those who program user interface front ends may use the 614 template to understand the format, range and meaning or attributes 615 available from Attribute Queries from Service Location. 617 Second, the template provides requirements for those who program 618 Service Agents for a particular Service Type. The attributes in the 619 Service Template must be assigned values to be associated with the 620 service: URL advertisement. 622 Finally, the template provides a mechanism for the Service Location 623 Protocol to discover Service Type specific Service Discovery 624 Multicast Addresses. The template itself is a service of type 625 "service-template". A User Agent obtains the template in order to 626 discover which multicast address to use for issuing requests to 627 Service Agents. Service Agents obtain the template to discover which 628 multicast group to join in order to receive multicast User Agent 629 requests. Both the Directory Agent and Service Agent will use the 630 templates in order to associate the Service Type string with the 631 correct Service Discovery Multicast Address in the SLP's Service Type 632 Reply. 634 All that is required to make this work, is to run a Service Agent 635 which advertises the set of templates of all services supported in 636 the network. ("The network" here refers to a network which has 637 multicast routing support with a maximum multicast TTL of 32. That 638 is, a "site.") 640 4. A Process For Standardizing New Service Types 642 New Service Types can be suggested simply by providing a Service Type 643 template and a short description of the use for the service: URL. 644 This should have its 'Version' attribute set to "0.0" initially. 646 The minor version number will increment once with each change until 647 it achieves 1.0. There is no guarantee any version of the service 648 template will be backwards compatible before it reaches 1.0. 650 Once a service template has reached 1.0, the definition is "frozen" 651 for that version. New templates may be defined, of course, to refine 652 that definition, but they must follow these rules: 654 - Any new attribute defined for the template will increase 655 the minor version number by one. All other attributes 656 for the version must continue to be supported as before. 657 A client which supports 1.x can still use later versions 658 of 1.y (where x 1219 "version = 0.0 1221 Language tag = en 1223 Mailboxes = larry, curly, moe, shemp 1225 APOP = FALSE 1227 Policy = Mail should not be left on the server." 1229 A translation of these attributes could be associated with the same 1230 URL to make the policy readable to non-English speakers. For 1231 example, the following is a translation to German: 1233 "version = 0.0 1235 Language tag = de 1237 Mailboxes = larry, curly, moe, shemp 1238 APOP = FALSE 1240 Anweisung = Mail darf nicht auf dem Server bleiben." 1242 Note that only the last attribute is translated. That is because 1243 version and Language tag are not translated (see Section 3.4.2.) and 1244 Mailboxes and APOP are marked with a 'L' in the POP3 template. 1246 7. Security Considerations 1248 Security considerations are not discussed in this memo. 1250 8. Internationalization Considerations 1252 The service: URL itself must be encoded using the rules set forth in 1253 [RFC1738]. The character set encoding is limited to specific ranges 1254 within the US-ASCII character set [ASCII]. 1256 The attribute information associated with the service: URL may be 1257 expressed in any character set, and in any language. 1259 8.1. Character Set identification and use 1261 The way of identifying the character set used is the IANA Character 1262 Set registry official name. [CHAR-REG] 1264 It can be assumed that US-ASCII [ASCII] will be supported. 1266 For other encodings, the repository of the service template or the 1267 protocol which transmits attributes (for registration or query 1268 purposes) must be able to identify the encoding using an external 1269 mechanism. It would make no sense to use an 'internal' designation 1270 for marking the character encoding, as the attribute information is 1271 itself string encoded. The Service Location Protocol [SLP] makes 1272 the character encoding for each registration, query and query result 1273 explicit in the protocol header, for example. 1275 All attribute information in a single transmission, file, etc. MUST 1276 be in the same character encoding. 1278 8.2. Language identification and translation 1280 The language used in attribute string should be identified using a 1281 Language tag as defined by [RFC1766]. 1283 All strings used in attributes (tags and values) are assumed to be 1284 able to be translated unless explicitely defined as should be 1285 literal, so that best effort translation (see below) will not 1286 obfuscate strings which are meant to be interpreted by a program, not 1287 a person. 1289 There are two ways to go about translation: Standardization and best 1290 effort. 1292 When the service type is standardized, more than one document may be 1293 submitted for review. One service type description is registered for 1294 each language. These descriptions must be kept in sync, so that when 1295 a service type template is updated in one language, all the 1296 translations are (or eventually are) reflect the same semantics. 1298 If no document exists describing the standard translation of the 1299 service type, a 'best effort' translation for strings may be done. 1301 A given service: URL may have several sets of attributes associated 1302 with it. Each set may be localized to a particular language. 1303 Mechanisms for obtaining service attributes MUST be parameterized to 1304 allow selection of language by Language tag. This way, users may 1305 access the same information in their own language. 1307 9. Bibliography 1309 [ABNF] D. Crocker, "Augmented BNF for Syntax Specifications: 1310 ABNF", Work in progress, November 1996. 1312 [ASCII] "Coded Character Set -- 7-bit American Standard code 1313 for Information Interchange", ANSI X3.4-1986. 1315 [CHAR-REG] IANA Character Set registry, . 1318 [FINDING] R. Moats, M. Hamilton, "Finding Stuff (Providing 1319 information to support service discovery)", Work in 1320 progress, November 1996. 1322 [NFSURL] B. Callaghan, "NFS URL Scheme", Work in progress, 1323 October, 1996. 1325 [RFC2055] B. Callaghan, "WebNFS Server Specification", RFC 2055. 1326 July 1996. 1328 [RFC2054] B. Callaghan, "WebNFS Client Specification", RFC 2054. 1329 July 1996. 1331 [RFC1939] J. Myers, M. Rose, "Post Office Protocol - Version 3", 1332 RFC 1939. May 1996. 1334 [RFC1759] R. Smith, F. Wright, T. Hastings, S. Zilles, J. 1335 Gyllenskog, "Printer MIB", RFC 1759. March 1995. 1337 [RFC1766] H. Alvestrand, "Tags for the Identification of 1338 Languages", RFC 1766. March 1995. 1340 [RFC1738] T. Berners-Lee, L. Masinter & M. McCahill, "Uni- 1341 form Resource Locators (URL)", RFC 1738. December 1342 1994. 1344 [RFC1734] J. Myers, "POP3 AUTHentication command", RFC 1734. 1345 December 1994. 1347 [RFC1179] L. McLaughlin III, "Line Printer Daemon Protocol", 1348 RFC 1179. August 1990. 1350 [SLP] J. Veizades, E. Guttman, C. Perkins & S. Kaplan, 1351 Service Location Protocol", Work in progress, 1352 November 1996. 1354 10. Author's Address 1356 Erik Guttman 1358 Sun Microsystems, Inc. 1359 Gaisbergstr. 6 1360 D-69115 Heidelberg 1361 Germany 1363 Phone: +1 415 336 6697 1364 email: Erik.Guttman@eng.sun.com 1366 This memo expires on May 20, 1997