TOC 
Network Working GroupD. Smith, Ed.
Internet-DraftAlgenta
Expires: October 22, 2004April 23, 2004

Internet Relay Chat (IRC) Client to Client Protocol (DCC2) Connection Negotiation

draft-smith-irc-dcc2-negotiation-00

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.

This Internet-Draft will expire on October 22, 2004.

Copyright Notice

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

The Direct Client Connection v2 (DCC2) connection negotiation specification describes how to establish connections between individual IRC clients. This draft describes a direct client connection protocol which supports the publishing of supported protocol options and connection negotiation. The DCC2 protocol is intended to be part of the IRC Client to Client Protocol (CTCP) framework.


Table of Contents

1.  Introduction
    1.1  Background
    1.2  Motivation
    1.3  Conventions
2.  DCC2 Overview
3.  DCC2 Message Encapsulation
4.  Tokens
    4.1  DCC2 Publication Tokens
        4.1.1  Network
        4.1.2  Transport
        4.1.3  TransportSecurity
        4.1.4  Application
        4.1.5  NAT
        4.1.6  SID
    4.2  DCC2 Connection Tokens
        4.2.1  IPv4
        4.2.2  IPv6
        4.2.3  Port
        4.2.4  ErrorTokens
        4.2.5  ErrorMessage
    4.3  DCC2 IRCFile Transfer Tokens
        4.3.1  File
        4.3.2  Size
        4.3.3  Offset
        4.3.4  Multi
5.  DCC2 negotiation
    5.1  Publication of Connection Parameters
        5.1.1  Publication Description
        5.1.2  Publish Syntax
        5.1.3  Publication Examples
    5.2  Accepting of Connection Parameters
        5.2.1  Accepting a negotiation
        5.2.2  Accept Syntax
        5.2.3  Accept Examples
    5.3  Connecting
        5.3.1  Establishing the TCP connection
        5.3.2  Negotiated DCC2 message
        5.3.3  Final negotiated Examples
6.  Examples
    6.1  DCC2 Chat Session
    6.2  DCC2 File Session
    6.3  DCC2 Nat Traversal
7.  Backwards Compatibility with historic DCC
8.  Security Considerations
9.  Notes
10.  Acknowledgments
§.  References
§  Author's Address
§  Intellectual Property and Copyright Statements



 TOC 

1. Introduction

1.1 Background

The Direct Client Connection 2.0 (DCC2) is a specification currently under development by the IRC Client Author's community.

DCC2 creates a framework for standardized connection negotiation between IRC clients. DCC2's design allows clients to automatically negotiate acceptable connection parameters, and makes it possible for users' clients to review the parameters and automate decision-making in the connection negotiation process.

For more information on the DCC2 please consult the DCC2 community documentation.

1.2 Motivation

The current DCC protocol does not address IPv4 vs. IPv6 issues, SSL/TLS encryption negotiation, NAT and Firewall traversal, or multiple file/directory file transfers. Historic DCC file transfers are also flawed in requiring acknowledgement of received bytes during the transfer, something that the underlying TCP protocol already ensures. Many IRC clients have implemented extensions that attempt to solve these problems, but the result has been fragmentation of the historic DCC protocol. This fragmentation is to a point where only the most simple functions work between different clients.

DCC2 has been introduced to solve these problems and insure interoperability between all IRC clients. The DCC2 negotiation system has also been designed to be extensible to incorporate future technological developments more easily that the original IRCII DCC implementation.

1.3 Conventions

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" in this document are to be interpreted as described in RFC-2119Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997.[1].


 TOC 

2. DCC2 Overview

DCC2 allows IRC clients to negotiate connection settings using a handshake mechanism for agreement to protocol usage. Protocols available on the offering client are published to the receiving client. The receiving client may then reply to the offering client, listing the subset of the available protocols that must be used. The receiving client also has the option to open the connection if the offering client cannot accept incoming connections.

The available protocols and options are presented as a list of case-insensitive, space separated tokens or token=value pairs. These tokens are standardized and listed here. Additional tokens can be added through the DCC2.org community process.


 TOC 

3. DCC2 Message Encapsulation

All DCC2 messages are encapsulated in a IRC PRIVMSG from one user to another, or from one user to a channel. The message portion of the PRIVMSG should begin and end with an octal \001 character. 

PRIVMSG nickname :/001DCC2 Application=IRCChat Network=IPv4,IPv6 TransportSecurity=SSL3,TLS1 SID=10a/001


 TOC 

4. Tokens

4.1 DCC2 Publication Tokens

4.1.1 Network

Specifies a list of possible network layers for the connection. Possible values include IPV4 and IPV6. 

Network=IPv4,IPv6

4.1.2 Transport

Specifies a list of possible transport layers for the connection. Possible values include TCP, SCTP and UDP 

Transport=Tcp

4.1.3 TransportSecurity

Specifies a list of possible encryption layers for this connection. Some possible values include SSL3 and TLS 

TransportSecurity=SSL3,TLS

4.1.4 Application

Specifies the common application service for this connection. There are many possible values for this token. Some possible values include IRCChat and IRCFile 

Application=IRCFile

4.1.5 NAT

Specify that incoming connections are not available. This token never has a value.

4.1.6 SID

Specify a session identifier for this negotiation. It may be possible to infer a session from a user, ip, or file information, however a session token must always be used to avoid ambiguity, especially with multiple concurrent negotiations to the same client since refusals can be silently ignored. This token must have a unique value for each negotiation with a remote user.

4.2 DCC2 Connection Tokens

4.2.1 IPv4

Specifies an IPv4 interface is present. When associated with a value, the IPV4 token specifies an IPv4 IP address in dotted-quad notation that can be connected to on a machine. 

; an IPv4 IP address in dotted-quad notation 
IPv4Address = 1*3digit "." 1*3digit "." 1*3digit "." 1*3digit

; example IPv4=192.168.23.43

4.2.2 IPv6

Specifies that an IPv6 interface is present. When associated with a value, the IPV6 token specifies an IPv6 IP address in colon-hexadecimal notation that can be connected to on a machine. 

 ;an IPv6 IP address in colon-hexadecimal  notation
IPv6Address =  hexseq | hexseq "::" [hexseq] | "::" [hexseq] 
hexseq = hex4 *( ":" hex4 ) 
hex4 = 1*4hexdig

; example IPv6=::C0A8:6464

4.2.3 Port

The port to connect to on the IPV4 and IPV6 addresses offered. The PORT token always has a value. 

Port=9834

4.2.4 ErrorTokens

Specifies the specific connection tokens that caused the error. 

ErrorTokens=Network,TransportSecurity

4.2.5 ErrorMessage

Specifies a user defined description of why the connection was refused or failed. 

ErrorMessage="I do not trust you."

4.3 DCC2 IRCFile Transfer Tokens

4.3.1 File

Specify the file name being sent. No directory information is included. If the filename contains spaces, it must be surrounded by double quotes. Limited to a single file transfer per session. Please see the ABNF for specific allowed characters. 

File="my file.txt"

4.3.2 Size

Specify the size of a FILE in bytes 

Size=93424

4.3.3 Offset

A byte offset at which to resume the FILE. 

Offset=7543

4.3.4 Multi

Specify that file name descriptions and sizes will be specified over the connection. The value is the size in bytes of the Multi XML file. 

Multi=9874


 TOC 

5. DCC2 negotiation

5.1 Publication of Connection Parameters

5.1.1 Publication Description

The offering client sends a message encapsulated using CTCP indicating the DCC2 options and connection settings supported by the client. Connection tokens without values are sent to the receiving client to indicate options that are supported. The Application, Network, and Sid tokens are always required in a publication message. Using the += delimiter marks a token group as optional.

Additional application level tokens can be sent along with the publication tokens. DCC2 file transfer tokens are sent with values to give the receiving client the context of the transfer. This file context is needed if the receiving client opens the listening connection due to NAT negotiation.

5.1.2 Publish Syntax

The DCC2 publication of connection negotiation parameters allows the client to advertise its supported protocols. The syntax follows, specified using ABNF rules (as per RFC2234Crocker, D. and P. Overel, Augmented BNF for Syntax Specifications: ABNF, November 1997.[3]): 

; Publication string, includes connection tokens and any optional application tokens
dcc2-publish       = `DCC2` 1*(space (ConnectionTokens | AppTokens))

; one or more of the connection tokens
ConnectionTokens = ConnectionToken [ 1* (space ConnectionToken)] 

; one of more application specific tokens
AppTokens = Apptoken [ 1* (space AppToken) ]
                     
; a connection token, optionally followed by a list of supported tokens.                                                           
ConnectionToken = 1*TokenChars [ ('=' | '+=' ) 1*TokenChars [ 1* (',' 1*TokenChars) ] ]

AppToken = 1*TokenChars [ ('=' | '+=' ) dcc2-quotedname ]

TokenChars = 1* (digit | alpha)

; any valid filename chars, double quotes are optional.  necessary with spaces.
dcc2-quotedname = 1*filechar | (%d34 1*(filechar | space ) %d34)
                                                                     
filechar = digit | alpha | filepunct

; valid file punct.  !#$%&'()+,-.=@[]^_{}~
filepunct = %d33 %d35-41 %d43-46 %d61 %d64 %d91 %d93-95 %d123 %d125-126

5.1.3 Publication Examples

5.1.3.1 DCC2 Chat

  1. Proposing a chat session negotiation, with either IPv4 or IPv6 and two optional encryption schemes available 

    		DCC2 Application=IRCChat Network=IPv4,IPv6 TransportSecurity+=SSL3,TLS1 SID=1

  2. Proposing a chat session negotiation, with only IPv6 available 

    		DCC2 Application=IRCChat Network=IPv6 SID=1

  3. Proposing a chat session negotiation, with only IPv4 available and the offering client cannot accept incoming connections 

    		DCC2 Application=IRCChat Network=IPv4 NAT SID=1

5.1.3.2 DCC2 File Sharing

  1. Proposing a file transfer session negotiation, with either IPv4 or IPv6 and two manditory encryption schemes available 

    		DCC2 Application=IRCFile Network=IPv4,IPv6 TransportSecurity=SSL3,TLS1 SID=1 Filename="some file.txt" Size=3423

  2. Proposing a file transfer session negotiation, with only IPv6 available 

    		DCC2 Application=IRCFile Network=IPv6 SID=1 Filename=somefile.txt Size=3423

  3. Proposing a file transfer session negotiation, with only IPv4 available and the offering client cannot accept incoming connections 

    		DCC2 Application=IRCFile Network=IPv4 NAT SID=1 Filename="somefile.txt" Size=3423

  4. Proposing a file transfer session negotiation, with only IPv4 available and using the DCC2 out of band file descriptions 

    		DCC2 Application=IRCFile Network=IPv4 SID=1 Multi=983

5.2 Accepting of Connection Parameters

5.2.1 Accepting a negotiation

The receiving client sends a DCC2 Accept message encapsulated using CTCP indicating the DCC2 options and connection settings that must be used for the transfer. This group of settings is a subset of the published parameters. Connection tokens without values may be sent to the offering client to indicate the protocols to be used.

If the offering client indicates it can not accept incoming connections, the receiving client should create a listening port on a supported interface, using the subset of the published parameters. The receiving client should then send the connection parameters with appropriate values to the offering client.

If neither the receiving or offering client can accept incoming connections, or can not agree on a common interface, a DCC2 CANNOTACCEPT message may be sent. The CannotAccept message must include the SID and ErrorTokens, and may include an ErrorMessage.

If the receiving client denies the connection negotiation, the received publication message can be silently ignored or a DCC2 REFUSED message may be sent. The Refused message must include the SID, and may include an ErrorMessage.

5.2.2 Accept Syntax

The DCC2 acceptance of connection negotiation parameters allows the clients to find common supported protocols. The syntax follows, specified using ABNF rules (as per RFC2234Crocker, D. and P. Overel, Augmented BNF for Syntax Specifications: ABNF, November 1997.[3]): 

; A DCC2 accept message, or a failure message with the SID
dcc2-response = 'DCC2' space ( 'Accept' | 'CannotAccept' | 'Refused' ) 1*(space Token) 		
                                                   
Token = 1*TokenChars [ '=' dcc2-quotedname ]

5.2.3 Accept Examples

5.2.3.1 DCC2 Chat

  1. Accepting a chat session negotiation, with either IPv4 or IPv6 and two encryption schemes available 

    		offering client sent:
		DCC2 Application=IRCChat Network=IPv4,IPv6 TransportSecurity+=SSL3,TLS1 SID=1
				
		receiving client would like to use IPv6 and TLS1 encryption sends:
		DCC2 Accept IPv6 TLS1 SID=1
		
		receiving client would like to use IPv4 and no encryption sends:
		DCC2 Accept IPv4 SID=1

  2. Accepting a chat session negotiation, with only IPv6 available 

    		offering client sent:
		DCC2 Application=IRCChat Network=IPv6 SID=2
		
		receiving client would like to use IPv6
		DCC2 Accept IPv6 SID=2
		
		receiving client does not have IPV6, and no IPV4 endpoint was offered
		DCC2 CannotAccept SID=2 ErrorTokens=Network

  3. Accepting a chat session negotiation, with only IPv4 available and the offering client cannot accept incoming connections 

    		offering client sent:
		DCC2 Application=IRCChat Network=IPv4 NAT SID=1
		
		receiving client will create an IPv4 connection:
		DCC2 Accept IPv4=192.168.100.100 Port=7323 SID=1
		
		receiving client can not accept incoming connections either:
		DCC2 CannotAccept SID=1 ErrorTokens=NAT

5.2.3.2 DCC2 File Sharing

  1. Accepting a file transfer session negotiation, with either IPv4 or IPv6 and two encryption schemes available 

    		offering client sent:
		DCC2 Application=IRCFile Network=IPv4,IPv6 TransportSecurity=SSL3,TLS1 Filename="some file.txt" Size=3423 SID=2
		
		receiving client would like to use IPV4 and SSL3:
		DCC2 Accept IPv4 SSL3 Filename="some file.txt" Size=3423 SID=2

  2. Accepting a file transfer session negotiation, with only IPv6 available 

    		offering client sent:
		DCC2 Application=IRCFile Network=IPv6 Filename=somefile.txt Size=3423 SID=a
		
		receiving client will accept the transfer and resume a download:
		DCC2 Accept IPv6 Filename=somefile.txt Size=3423 Offset=1202 SID=a
		
		receiving client cannot accept IPV6:
		DCC2 CannotAccept SID=a ErrorTokens=Network
		
		receiving client refuses the file:
		DCC2 Refused SID=a ErrorMessage="We've already got one!"

  3. Accepting a file transfer session negotiation, with only IPv4 available and the offering client cannot accept incoming connections 

    		offering client sent:
		DCC2 Application=IRCFile Network=IPv4 NAT Filename="somefile.txt" Size=3423 SID=1
		
		receiving client will accept the transfer and open a listening connection:
		DCC2 Accept IPv4=192.168.23.342 PORT=8732 Filename="somefile.txt" Size=3423 SID=1
		
		receiving client can not accept incoming connections either:
		DCC2 CannotAccept SID=1 ErrorTokens=NAT

  4. Accepting a file transfer session negotiation, with only IPv4 available and using the DCC2 out of band file descriptions 

    		offering client send:
		DCC2 Application=IRCFile Network=IPv4 Multi=983 SID=1
		
		receiving client will accept the file transfer:
		DCC2 Accept IPv4 Multi=983 SID=1
		
		receiving client does not support multi-file transfers:
		DCC2 CannotAccept SID=1 ErrorTokens=Multi

5.3 Connecting

5.3.1 Establishing the TCP connection

The offering client receives a DCC2 ACCEPT message encapsulated using CTCP indicating the DCC2 options and connection settings that will be used for the transfer. If the connection parameters have values, the receiving client is listening for a connection. The offering client will connect to the specified port. There is no need for an additional CTCP message

If the connection parameters do not have associated values, the offering client creates a listening socket using the protocols dictated by the ACCEPT message. The Offering client then sends another DCC2 Accept message using the parameters associated with the listening socket.

5.3.2 Negotiated DCC2 message

The DCC2 negotiation parameters have been specified to use a common supported protocol. The syntax specified using ABNF rules (as per RFC2234Crocker, D. and P. Overel, Augmented BNF for Syntax Specifications: ABNF, November 1997.[3]) is documented in the previous section.

5.3.3 Final negotiated Examples

5.3.3.1 DCC2 Chat

  1. Finalizing a chat session negotiation, using IPv6 and TLS1 

    		receiving client would like to use IPv6 and TLS1 encryption sends:
		DCC2 Accept IPv6 TLS1 SID=1
		
		offering client sends:
		DCC2 Accept IPv6=::C0A8:6464 Port=8543 TLS1 SID=1

  2. Finalizing a chat session negotiation, with only IPv6 available 

    		receiving client would like to use IPv6
		DCC2 Accept IPv6 SID=1
		
		offering client sends:
		DCC2 Accept IPv6=::C0A8:6464 Port=8543 SID=1

5.3.3.2 DCC2 File Sharing

  1. Finalizing a file transfer session negotiation, with either IPv4 or IPv6 and two encryption schemes available 

    		receiving client would like to resume using IPV4 and SSL3:
		DCC2 Accept IPv4 SSL3 Filename="some file.txt" Size=3423 Offset=1003 SID=2
		
		offering client sends:
		DCC2 Accept IPv4=192.168.34.231 Port=9341 SSL3 Filename="some file.txt" Size=3423 SID=2

  2. Finalizing a file transfer session negotiation with IPv6 

    		receiving client will accept the transfer:
		DCC2 Accept IPv6 Filename=somefile.txt Size=3423 SID=1
		
		offering client will send:
		DCC2 Accept IPv6=::C0A8:6464 Filename=somefile.txt Size=3423 SID=1

  3. Finalizing a file transfer session negotiation with IPv4 available and using the DCC2 out of band file descriptions 

    		receiving client will accept the file transfer:
		DCC2 Accept IPv4 Multi=983 SID=1
		
		offering client will send:
		DCC2 Accept IPv4=192.168.34.231 Port=9251 Multi=983 SID=1

 TOC 

6. Examples

6.1 DCC2 Chat Session

Proposing a chat session negotiation, with either IPv4 or IPv6 and manditory encryption with two schemes available. 

		; Offering client sends initial publication with manditory Transport Security
		DCC2 Application=IRCChat Network=IPv4,IPv6 TransportSecurity=SSL3,TLS1 SID=10a
		
		; Receiving client accepts using an ipv6 interface and tls1
		DCC2 Accept IPv6 TLS1 SID=10a
		
		; Offering client creates a listening port and sends connection information
		DCC2 Accept IPv6=::C0A8:6464 Port=4521 TLS1 SID=10a

6.2 DCC2 File Session

Proposing a file transfer with IPv6 and one optional encryption schemes available 

		; Offering client sends initial publication with optional Transport Security
		DCC2 Application=IRCFile Network=IPv6 TransportSecurity+=TLS1 SID=abde3 Filename="todo.txt" Size=98342
		
		; Receiving client accepts using an ipv6 interface and no encryption
		DCC2 Accept IPv6 SID=abde3 Filename="todo.txt" Size=98342
				
		; Offering client creates a listening port and sends connection information
		DCC2 Accept IPv6=::C0A8:6464 Port=3412 TLS1 SID=10a Filename="todo.txt" Size=98342

6.3 DCC2 Nat Traversal

Proposing a chat session negotiation, with either IPv4 or IPv6 and manditory encryption with two schemes available. 

		; Offering client sends initial publication with manditory Transport Security
		DCC2 Application=IRCChat Network=IPv4,IPv6 TransportSecurity=SSL3,TLS1 SID=405
		
		; Receiving client creates a listening port and sends connection information
		DCC2 Accept IPv6=::C0A8:6464 Port=7322 TLS1 SID=405

 TOC 

7. Backwards Compatibility with historic DCC

Historic DCC connections use a set of positional parameters to relate port and address information. Most clients ignore extra positional parameters in historic DCC, allowing DCC2 to be used in a backward compatible manner. If a client wishes to create a connection that could be possible under historic dcc, such as an ipv4 connection with no encryption or firewall traversal, the sending client can create a listening socket and send a historic dcc request. The client should append a DCC2 publication request to the end of the historic dcc request.

If the receiving client supports dcc2, and would like to use additional features such as encrypting for this connection, it can send a DCC2 accept message to the sending client instead of accepting the transfer. The sending client should then close the connection created for the historic dcc request, and create the proper DCC2 connection.

If the receiving client does not support DCC2, it will connect using the historic dcc procedure.


 TOC 

8. Security Considerations

Ports under 1024 are privileged on unix systems, and should not be used for direct client connections.

IRC client writers should be careful with directory structures when dealing with file sharing operations. Relative paths using ../ can lead to security risks

IRC clients should look carefully at the speed of sending DCC2 REFUSED and DCC2 CANNOTACCEPT due to the potential for flooding attacks. When possible the messages should be sent to give the user context as to why the transfer failed


 TOC 

9. Notes

This draft is also present on the DCC2 site at the address http://www.dcc2.org/specifications/draft-smith-irc-dcc2-negotiation-00.txt. Enriched HTML and XML versions can be found at the addresses http://www.dcc2.org/specifications/draft-smith-irc-dcc2-negotiation-00.htm and http://www.dcc2.org/specifications/draft-smith-irc-dcc2-negotiation-00.xml respectively. The XML version is compliant to RFC-2629Rose, M., Writing I-Ds and RFCs using XML, June 1999.[2].


 TOC 

10. Acknowledgments

This draft was produced by the DCC2 community; please see authors and contributors.

Thanks to Marshall Rose for his conversion tools from the RFC-2629Rose, M., Writing I-Ds and RFCs using XML, June 1999.[2] XML format to HTML and RFC.


 TOC 

11 References

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[2] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[3] Crocker, D. and P. Overel, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

 TOC 

Author's Address

  Dan Smith (editor)
  Algenta Technologies L.L.C.
  1640 Sky Line Dr
  Stevens Point, WI 54481
  USA
Phone:  01-608-213-2867
EMail:  dan @ algenta
URI:  http://www.algenta.com

 TOC 

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

Full Copyright Statement

Copyright (C) The Internet Society (2004). 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 assignees.

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.

Acknowledgment

Funding for the RFC Editor function is currently provided by the Internet Society.