INTERNET DRAFT Weibin Zhao draft-zhao-slp-attr-01.txt Henning Schulzrinne June 14, 2002 Columbia University Expires: December 14, 2002 Defining and Using Global Service Attributes in SLP Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes how to define and use global service attributes in the Service Location Protocol (SLP). A global service attribute is service type independent. Its name begins with the "service-" prefix. A global service attribute is defined using an attribute template, and can be imported into any service template. We show how to use global service attributes to query services across multiple service types, and to support multi-protocol services, multi-function devices, URL changes, and replicated server groups. Zhao/Schulzrinne Expires: December 14, 2002 [Page 1] Internet Draft SLP Global Service Attributes June 14, 2002 1. Introduction The Service Location Protocol (SLP [1]) provides a flexible framework for service discovery in IP networks. Currently, SLP only supports local service attributes in that any service attribute is defined and used in the context of a particular service type. In contrast, we refer to service attributes that are service type independent as global service attributes. In this document, we describe how to define and use global service attributes in SLP. A global service attribute is used for describing a common service property across all service types or for a service management purpose. In a sense, service URL and service scope list can be viewed as global service attributes. Other examples of global service attributes include service identifier [2], service transport protocol, and service replication name. Since a global attribute is defined without any service type context, and can be used in a Service Request (SrvRqst) with any service type, if it has the same name as a local attribute, then there will be a confusion on which is which. Therefore, a separate namespace is needed for global service attributes: any global service attribute name MUST begin with the "service-" prefix. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted according to RFC 2119 [3]. 2. The Definition of Global Service Attributes A global service attribute is defined using an attribute template. Normally each global service attribute is defined using a separate attribute template, but if several global service attributes are always used together, they MAY be defined in the same attribute template. Any service that uses a global service attribute needs to import the attribute's definition into its service template (similar to C include and Java import mechanism). This way, we can avoid defining the same attribute repeatedly in multiple service templates, and ensure a consistent definition of the attribute. 2.1. Attribute Template Syntax An attribute template is a simplified version of the service type template (RFC 2609 [4]). It is defined using the following ABNF [5]: attr-template = version attr-defs version = "# attribute-template-version" version-no term version-no = version-no from section 3.1 of RFC 2609 Zhao/Schulzrinne Expires: December 14, 2002 [Page 2] Internet Draft SLP Global Service Attributes June 14, 2002 term = term from section 3.1 of RFC 2609 attr-defs = 1*(attr-def) attr-def = attr-def from section 3.1 of RFC 2609 2.2. Attribute Template File Name An attribute template file has a naming convention (similar to the service type template file [4]) defined using the following ABNF. attr-tem-fname = attribute-name "." version-no "." langtag attribute-name = id from section 3.1 of RFC 2609 version-no = version-no from section 3.1 of RFC 2609 langtag = langtag from section 3.1 of RFC 2609 The file name of an attribute template is derived from the first attribute name it defines. For example, if a global service attribute "service-attr-x" is the first attribute in an attribute template, the version number is 1.0, and the language tag is "en", then the attribute template file name is "service-attr-x.1.0.en". 2.3. Importing Global Service Attributes In order to support importing global service attributes, the ABNF of the service type template defined in RFC 2609 [4] needs to be extended as follows. attr-defs = *( attr-def / keydef / import-line ) import-line = "import" attr-tem-fname attr-tem-fname = attr-tem-fname from section 2.2 of this document 2.4. Examples of Attribute Templates 2.4.1. The "service-identifier" Attribute Template ------------------attribute template begins here------------------- # attribute-template-version = 1.0 service-identifier = string # It uniquely and persistently identifies a service instance. -------------------attribute template ends here-------------------- 2.4.2. The "service-transport-protocol" Attribute Template ------------------attribute template begins here------------------- # attribute-template-version = 1.0 Zhao/Schulzrinne Expires: December 14, 2002 [Page 3] Internet Draft SLP Global Service Attributes June 14, 2002 service-transport-protocol = string M # It specifies the transport protocols supported by a service # location. udp,tcp,sctp -------------------attribute template ends here-------------------- 2.4.3. The "service-replication-name" Attribute Template ------------------attribute template begins here------------------- # attribute-template-version = 1.0 service-replication-name = string # It uniquely identifies a replicated server group for a service. -------------------attribute template ends here-------------------- 3. The Use of Global Service Attributes A global service attribute can be used in any place where a local service attribute is appropriate, such as the attribute predicate in a SrvRqst, the attribute list in a Service Registration (SrvReg) or Attribute Reply (AttrRply), and the attribute tag in a Service Deregistration (SrvDeReg) or Attribute Request (AttrRqst). 3.1. Performing Service Queries across Multiple Service Types In a SrvRqst, when both local and global service attributes are used, exactly one service type MUST be specified. But when only global service attributes are used, multiple service types or a service type wildcard can be specified. A service type wildcard is defined as an empty service type string; the length of the service type string is zero. By using global service attributes, and multiple service types or a service type wildcard in a SrvRqst, we can more efficiently perform service queries across multiple or all service types. For example, to find all services that support the Stream Control Transmission Protocol (SCTP [6]), we can use a single SrvRqst that has a service type wildcard, and a predicate of "service-transport- protocol=sctp". In contrast, current SLP needs three steps to accomplish this discovery requirement: (1) use a Service Type Request (SrvTypeRqst) to obtain a list of service types, (2) use a separate SrvRqst to query services of each service type that support SCTP, and (3) combine the query results together. Zhao/Schulzrinne Expires: December 14, 2002 [Page 4] Internet Draft SLP Global Service Attributes June 14, 2002 3.2. Supporting Multi-Protocol Services A service may support multiple access protocols, having a separate URL for each access protocol. For example, a multi-protocol printer that supports IPP [7] and LPR access protocols may have two URLs as follows: service:printer:ipp://mpp.example.com and service:printer:lpr://mpp.example.com. A multi-protocol service advertises each of its access protocols separately, but all advertisements use the same service identifier to indicate that they belong to the same service instance. A UA can discover all advertisements of a multi-protocol service by specifying the service identifier and the service type (or a service type wildcard) in a SrvRqst. 3.3. Supporting Multi-Function Devices A device may provide multiple types of services, such as scanning and printing services. A multi-function device advertises each service type separately, but all advertisements use the same service identifier to indicate that they belong to the same service instance. A UA can discover all advertisements of a multi-function device by specifying the device's service identifier and a service type wildcard (or all the service types the device supports) in a SrvRqst. 3.4. Supporting URL Changes A service may change its URL. Once this happens, a UA cannot find the same service again by using its old URL; but the UA can find the same service again by using its service identifier. 3.5. Supporting Replicated Server Groups A service may be provisioned by a group of replicated servers; each server has a separate URL, and a separate service identifier. A replicated server group advertises each server separately, but all advertisements use the same service replication name to indicate that they belong to the same server group. A UA can discover all advertisements of a replicated server group by specifying the service replication name and the service type (or a service type wildcard) in a SrvRqst. 4. Security Considerations The security considerations for RFC 2609 apply to this document. 5. Acknowledgments Erik Guttman's draft on the serviceid: URI scheme [2] motivated this Zhao/Schulzrinne Expires: December 14, 2002 [Page 5] Internet Draft SLP Global Service Attributes June 14, 2002 document directly. Jim Mayer, Mark Bakke and Ira McDonald gave good suggestions. The authors also benefit from the discussions in the SLP mailing list. 6. References [1] E. Guttman, C. Perkins, J. Veizades and M. Day, "Service location protocol, version 2", RFC 2608, June 1999. [2] E. Guttman, "The serviceid: URI Scheme for Service Location", Internet Draft, January 2002. [3] S. Bradner, "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997. [4] E. Guttman, C. Perkins and J. Kempf, "Service Templates and Service: Schemes", RFC 2609, June, 1999. [5] D. Crocker and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [6] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [7] R. Herriot, S. Butler, P. Moore, R. Turner and J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000. 7. Authors' Addresses Weibin Zhao Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003 Email: {zwb,hgs}@cs.columbia.edu 8. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are Zhao/Schulzrinne Expires: December 14, 2002 [Page 6] Internet Draft SLP Global Service Attributes June 14, 2002 included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Zhao/Schulzrinne Expires: December 14, 2002 [Page 7]