Movatterモバイル変換

Network Working Group                                         E. GuttmanRequest for Comments: 3059                              Sun MicrosystemsCategory: Standards Track                                  February 2001Attribute List Extension for the Service Location ProtocolStatus of this Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2001).  All Rights Reserved.Abstract   The Service Location Protocol, Version 2 (SLPv2) provides a mechanism   for a service to be discovered in a single exchange of messages.   This exchange of messages does not presently include any of the   service's attributes.  This document specifies a SLPv2 extension   which allows a User Agent (UA) to request a service's attributes be   included as an extension to Service Reply messages.  This will   eliminate the need for multiple round trip messages for a UA to   acquire all service information.Table of Contents1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .21.1. Terminology . . . . . . . . . . . . . . . . . . . . . . .21.2. Notation Conventions  . . . . . . . . . . . . . . . . . .32. Attribute List Extension  . . . . . . . . . . . . . . . . . . .33. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .44. Internationalization Considerations . . . . . . . . . . . . . .45. Security Considerations . . . . . . . . . . . . . . . . . . . .46. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .4   References . . . . . . . . . . . . . . . . . . . . . . . . . . . .5   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .5   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .6Guttman                     Standards Track                     [Page 1]

RFC 3059           Attribute List Extension for SLPv2      February 20011. Introduction   The Service Location Protocol, Version 2 [3] provides a mechanism for   a service to be discovered in a single exchange of messages.  The UA   sends a Service Request message and the DA or SA (as appropriate)   sends a Service Reply message.   It is clearly advantageous to be able to obtain all service   information at once.  The Service Location Protocol separates   messages which obtain different classes of information.  This   extension enables an optimization to the basic exchange of messages,   which currently does not include service attributes in Service Reply   messages.   This document specifies a SLPv2 extension which allows a UA to   request that a service's attributes be included in Service Reply   messages.  This will eliminate the need for multiple round trip   messages for a UA to acquire all service information.   If the DA or SA does not support the Attrlist extension, it will   simply return a Service Reply (without the extension).  Support of   this extension is OPTIONAL.  Existing implementations will ignore the   Attrlist extension since it has been assigned a identifying number   from the range which indicates that the receiver MUST ignore the   extension if it is not recognized.  SeeRFC 2608 [3].   If the UA receives a Service Reply message without an Attrlist   Extension it must assume the SA or DA does not support the extension.   In this case, the UA must send an Attribute Request for each URL it   obtains in the Service Reply message in order to obtain the   attributes for these services.1.1. Terminology   User Agent (UA)         A process working on the user's behalf to establish contact         with some service.  The UA retrieves service information from         the Service Agents or Directory Agents.   Service Agent (SA)         A process working on the behalf of one or more services to         advertise the services.   Directory Agent (DA)         A process which collects service advertisements.  There can         only be one DA present per given host.Guttman                     Standards Track                     [Page 2]

RFC 3059           Attribute List Extension for SLPv2      February 20011.2. Notation Conventions   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   document are to be interpreted as described inRFC 2119 [2].2. Attribute List Extension   The format of the Attribute List Extension is as follows:       0                   1                   2                   3       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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |      Extension ID = 0x0002    |     Next Extension Offset     |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      | Offset, contd.|      Service URL Length       |  Service URL  /      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |     Attribute List Length     |         Attribute List        /      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |# of AttrAuths |(if present) Attribute Authentication Blocks.../      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   The Extension ID is 0x0002.   The Next Extension Offset value indicates the position of the next   extension as offset from the beginning of the SLP message.  If the   next extension offset value is 0, there are no more extensions in the   message.   A UA sends an Attribute List Extension with a Service Request.  The   Service URL Length and Attribute List Length are set to 0 and the   Service URL and Attribute List fields omitted in this case.  The UA   thereby requests that the SA or DA include an Attribute List   Extension in its Service Reply by including such an 'empty' Attribute   List Extension in the Service Request.   A SA or DA which supports the Attribute List Extension returns one   Attribute List extension for every URL Entry in the Service Reply   message.  The order of the Attribute List Extensions SHOULD be the   same as the URL Entries in the Service Reply.   The Service URL [4] identifies the corresponding URL Entry.   The Attribute List field is the entire attribute list of the service.   These attributes must be in the same language as that indicated in   the Service Request message.Guttman                     Standards Track                     [Page 3]

RFC 3059           Attribute List Extension for SLPv2      February 2001   If the Service Request message includes a SLP SPI string, then the   attribute list extension MUST include an authentication block.  If   the SA or DA does not support or is unable to return an   authentication block for the SLP SPI included in the Service Request,   then the SA or DA MUST NOT return an Attribute List Extension.  The   format of the authentication block(s) is exactly the same as would be   included in an Attribute Reply or Service Registration message.3. IANA Considerations   IANA has assigned an extension ID number of 0x0002 for the Attribute   List Extension.4. Internationalization Considerations   The Service Location Protocol, version 2 has mechanisms for allowing   attributes to be transmitted with explicit language tagging [6].  The   same mechanisms are used for this protocol extension.5. Security Considerations   The Service Location Protocol, version 2 has mechanisms for allowing   authenticators to be returned with attribute lists so that UAs are   able to verify a digital signature over the attributes they obtain.   This same mechanism is used for this protocol extension.  The   Attribute List Extension used in conjunction with SLPv2 is no less   secure than SLPv2 without the extension.6. Acknowledgments   The author benefited from preliminary conversations about this   extension with Charlie Perkins.Guttman                     Standards Track                     [Page 4]

RFC 3059           Attribute List Extension for SLPv2      February 2001References   [1] Bradner, S., "The Internet Standards Process -- Revision 3",BCP9,RFC 2026, October 1996.   [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement       Levels",BCP 14,RFC 2119, March 1997.   [3] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service       Location Protocol, Version 2",RFC 2608, June 1999.   [4] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and       service: Schemes",RFC 2609, June 1999.   [5] Narten, T and H. Alvestrand, "Guidelines for Writing an IANA       Considerations Section in RFCs",BCP 26,RFC 2434, October 1998.   [6] Alvestrand, H., "Tags for the Identification of Languages",BCP47,RFC 3066, January 2001.Author's Address   Erik Guttman   Sun Microsystems   Eichhoelzelstr. 7   74915 Waibstadt   Germany   Phone:    +49 6227 356 202   EMail:    Erik.Guttman@sun.comGuttman                     Standards Track                     [Page 5]

RFC 3059           Attribute List Extension for SLPv2      February 2001Full Copyright Statement   Copyright (C) The Internet Society (2001).  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   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.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Guttman                     Standards Track                     [Page 6]