idnits 2.17.1 draft-guttman-svrloc-attrlist-ext-04.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (16 October 2000) is 8593 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 197, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 1766 (ref. '6') (Obsoleted by RFC 3066, RFC 3282) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Erik Guttman 3 INTERNET DRAFT Sun Microsystems 4 16 October 2000 5 Expires in six months 7 Attribute List Extension for the Service Location Protocol 8 draft-guttman-svrloc-attrlist-ext-04.txt 10 Status of This Memo 12 This document is a submission by the Service Location Working Group 13 of the Internet Engineering Task Force (IETF). Comments should be 14 submitted to the srvloc@srvloc.org mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The Service Location Protocol, Version 2 provides a mechanism for a 38 service to be discovered in a single exchange of messages. This 39 exchange of messages does not presently include any of the service's 40 attributes. This document specifies a SLPv2 extension which allows 41 a User Agent to request a service's attributes be included as an 42 extension to Service Reply messages. This will eliminate the need 43 for multiple round trip messages for a UA to acquire all service 44 information. 46 Table of Contents 48 Status of This Memo 1 50 Abstract 1 52 1. Introduction 2 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.2. Notation Conventions . . . . . . . . . . . . . . . . . . 3 56 2. Attribute List Extension 3 58 3. IANA Considerations 4 60 4. Internationalization Considerations 4 62 5. Security Considerations 4 64 6. Acknowledgments 4 66 References 4 68 Author's Address 5 70 Full Copyright Statement 5 72 1. Introduction 74 The Service Location Protocol, Version 2 [3] provides a mechanism for 75 a service to be discovered in a single exchange of messages. The UA 76 sends a Service Request message and the DA or SA (as appropriate) 77 sends a Service Reply message. 79 It is clearly advantageous to be able to obtain all service 80 information at once. The Service Location Protocol separates 81 messages which obtain different classes of information. This 82 extension enables an optimization to the basic exchange of messages, 83 which currently does not include service attributes in Service Reply 84 messages. 86 This document specifies a SLPv2 extension which allows a User Agent 87 to request that a service's attributes be included in Service Reply 88 messages. This will eliminate the need for multiple round trip 89 messages for a UA to acquire all service information. 91 If the DA or SA does not support the SLPv2 extension, it will simply 92 return a Service Reply. Support of this extension is OPTIONAL. 94 1.1. Terminology 96 User Agent (UA) 97 A process working on the user's behalf to establish 98 contact with some service. The UA retrieves service 99 information from the Service Agents or Directory Agents. 101 Service Agent (SA) 102 A process working on the behalf of one or more services 103 to advertise the services. 105 Directory Agent (DA) 106 A process which collects service advertisements. There 107 can only be one DA present per given host. 109 1.2. Notation Conventions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [2]. 115 2. Attribute List Extension 117 The format of the Attribute List Extension is as follows: 119 0 1 2 3 120 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Extension ID = 0x0002 | Next Extension Offset | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Offset, contd.| Service URL Length | Service URL / 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Attribute List Length | Attribute List / 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 |# of AttrAuths |(if present) Attribute Authentication Blocks.../ 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 The Extension ID is 0x0002. 133 The Next Extension Offset value indicates the position of the next 134 extension as offset from the beginning of the SLP message. If the 135 next extension offset value is 0, there are no more extensions in the 136 message. 138 A UA sends an Attribute List Extension with a Service Request. The 139 Service URL Length and Attribute List Length are set to 0 and the 140 Service URL and Attribute List fields omitted in this case. The UA 141 thereby requests that the SA or DA include an Attribute List 142 Extension in its Service Reply by including such an 'empty' Attribute 143 List Extension in the Service Request. 145 A SA or DA which supports the Attribute List Extension returns one 146 Attribute List extension for every URL Entry in the Service Reply 147 message. The order of the Attribute List Extensions SHOULD be the 148 same as the URL Entries in the Service Reply. 150 The Service URL [4] identifies the corresponding URL Entry. 152 The Attribute List field is the entire attribute list of the service. 153 These attributes must be in the same language as that indicated in 154 the Service Request message. 156 If the Service Request message includes a SLP SPI string, then the 157 attribute list extension MUST include an authentication block. If 158 the SA or DA does not support or is unable to return an 159 authentication block for the SLP SPI included in the Service Request, 160 then the SA or DA MUST NOT return an Attribute List Extension. The 161 format of the Attribute List extension is exactly the same as would 162 be included in an Attribute Reply or Service Registration message. 164 3. IANA Considerations 166 According to RFC 2608: 168 New SLP Extensions with types in the range 2-65535 may be 169 registered following review by a Designated Expert [5]. 171 The extension ID number for the Attribute List Extension is 0x0002. 172 This ID has been selected by the Designated Expert for SLPv2, and 173 must be registered with IANA. 175 4. Internationalization Considerations 177 The Service Location Protocol, version 2 has mechanisms for allowing 178 attributes to be transmitted with explicit language tagging [6]. The 179 same mechanisms are used for this protocol extension. 181 5. Security Considerations 183 The Service Location Protocol, version 2 has mechanisms for allowing 184 authenticators to be returned with attribute lists so that UAs are 185 able to verify a digital signature over the attributes they obtain. 186 This same mechanism is used for this protocol extension. The 187 Attribute List Extension used in conjunction with SLPv2 is no less 188 secure than SLPv2 without the extension. 190 6. Acknowledgments 192 The author benefited from preliminary conversations about this 193 extension with Charlie Perkins. 195 References 197 [1] S. Bradner. The Internet Standards Process -- Revision 3. RFC 198 2026, October 1996. 200 [2] S. Bradner. Key Words for Use in RFCs to Indicate Requirement 201 Levels. RFC 2119, March 1997. 203 [3] E. Guttman, C. Perkins, J. Veizades, M. Day. Service Location 204 Protocol, Version 2. RFC 2608, June 1999 206 [4] E. Guttman, C. Perkins, J. Kempf. Service Templates and service: 207 Schemes. RFC 2609, June 1999 209 [5] T. Narten, H. Alvestrand. Guidelines for Writing an IANA 210 Considerations Section in RFCs. RFC 2434, October 1998. 212 [6] H. Alvestrand. Tags for the Identification of Languages. RFC 213 1766, March 1995. 215 Author's Address 217 Erik Guttman 218 Sun Microsystems 219 Eichhoelzelstr. 7 220 74915 Waibstadt 221 Germany 223 Phone: +49 7263 911 701 224 Email: Erik.Guttman@sun.com 226 7. Full Copyright Statement 228 Copyright (C) The Internet Society (1999). All Rights Reserved. 230 This document and translations of it may be copied and furnished to 231 others, and derivative works that comment on or otherwise explain it 232 or assist in its implementation may be prepared, copied, published 233 and distributed, in whole or in part, without restriction of any 234 kind, provided that the above copyright notice and this paragraph 235 are included on all such copies and derivative works. However, 236 this document itself may not be modified in any way, such as by 237 removing the copyright notice or references to the Internet Society 238 or other Internet organizations, except as needed for the purpose 239 of developing Internet standards in which case the procedures 240 for copyrights defined in the Internet Standards process must be 241 followed, or as required to translate it into languages other than 242 English. 244 The limited permissions granted above are perpetual and will not be 245 revoked by the Internet Society or its successors or assigns. 247 This document and the information contained herein is provided on an 248 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 249 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 250 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 251 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 252 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."