From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3059.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc3059.txt (limited to 'doc/rfc/rfc3059.txt') diff --git a/doc/rfc/rfc3059.txt b/doc/rfc/rfc3059.txt new file mode 100644 index 0000000..e348137 --- /dev/null +++ b/doc/rfc/rfc3059.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group E. Guttman +Request for Comments: 3059 Sun Microsystems +Category: Standards Track February 2001 + + + Attribute List Extension for the Service Location Protocol + +Status 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 Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.2. Notation Conventions . . . . . . . . . . . . . . . . . . 3 + 2. Attribute List Extension . . . . . . . . . . . . . . . . . . . 3 + 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Internationalization Considerations . . . . . . . . . . . . . . 4 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 + References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 6 + + + + + + + + +Guttman Standards Track [Page 1] + +RFC 3059 Attribute List Extension for SLPv2 February 2001 + + +1. 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. See RFC 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 2001 + + +1.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 in RFC 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 2001 + + +References + + [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, 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", BCP + 47, 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.com + + + + + + + + + + + + + + + + + + + + + +Guttman Standards Track [Page 5] + +RFC 3059 Attribute List Extension for SLPv2 February 2001 + + +Full 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] + -- cgit v1.2.3