1 files changed, 339 insertions, 0 deletions
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]
+