INTERNET DRAFT EXPIRES NOVEMBER 2000 INTERNET DRAFT Network Working Group D. Croft Internet Draft Infotrek May 2000 Telnet URL Transmission Option Status of this Memo This document is an Internet-Draft and is in full comformance with all provisions of Section 10 of RFC 2026 [5]. 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 Distribution of this memo is unlimited. Abstract This document defines an extension to the Telnet protocol by which compliant applications may exchange URL information to provide hyperlinks for the user. Comments are invited on both this protocol, and on this document itself. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Table of Contents 1. Command Name and Code . . . . . . . . . . . . . . . . . . . . N 2. Command Meanings . . . . . . . . . . . . . . . . . . . . . . . N 3. Default Behaviour . . . . . . . . . . . . . . . . . . . . . . N 4. Motivation for the Option . . . . . . . . . . . . . . . . . . N 5. Description of the Option . . . . . . . . . . . . . . . . . . N Croft Internet Draft [Page 1] [DRAFT] Telnet URL Transmission Option May 2000 6. Implementation Issues . . . . . . . . . . . . . . . . . . . . N 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . N 8. Security Considerations . . . . . . . . . . . . . . . . . . . N 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . N 10. Author's Address . . . . . . . . . . . . . . . . . . . . . . . N 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . N 1. Command Name and Code SEND-URL . . . 48 IS . . . . 0 END . . . . 4 2. Command Meanings The meanings of the tokens IAC, WILL, WONT, DO, DONT, SB and SE are as defined in the Telnet Protocol specification [1]. IAC WILL SEND-URL Sender requests permission to, or confirms that it will now send URL information in sub-negotiations. IAC WONT SEND-URL Sender refuses to start, or confirms that it will no longer send URL information in sub-negotiations. IAC DO SEND-URL Sender requests that the receiver start, or confirms that the receiver may begin sending URL information in sub-negotiations. IAC DONT SEND-URL Sender demands that the receiver stop, or confirms that the receiver will no longer send URL information. IAC SB SEND-URL IS ... IAC SE Sender states that the text following this sub-negotiation is to be considered a hyperlink, with the target URL being the data contained within this sub-negotiation. The code for IS is 0. Only the end that has already negotiated that it WILL send URL information may send this sub-negotiation. Croft Internet Draft [Page 2] [DRAFT] Telnet URL Transmission Option May 2000 IAC SB SEND-URL END IAC SE Sender states that the in-stream text is to no longer be treated as a hyperlink. The code for END is 4. Only the end that has already negotiated that it WILL send URL information may send this sub-negotiation. 3. Default Behaviour WONT SEND-URL URL information will not be sent. DONT SEND-URL URL information will not be expected. 4. Motivation for the Option With the multitude of different types of service available using the Telnet protocol, many of which have related WWW pages, a need has been identified to extend the protocol so that URLs can be easily followed. The primary interest of this author is in the extension of multiplayer online text games (MUDs) to support this option. This document defines a simple extension to the Telnet protocol, and is fully backward-compatible using the Telnet option negotation model so that clients or servers which do not understand the protocol defined in this document will operate normally. 5. Description of the Option Willingness to exchange URL information is agreed upon via conventional Telnet option negotiation. WILL and DO are used only to obtain and grant permission for future discussion. The actual exchange of URL information occurs only with the option subcommands (IAC SB SEND-URL ...) Within this document, the term "server" is used to refer to the program that has negotiated that it WILL SEND-URL and thus will be sending URLs. The term "client" refers to the program which has indicated that it will accept URL information using DO SEND-URL. Of course, the protocol is fully asymmetric (it must be negotiated separately for each direction), but this nomenclature is used in anticipation of the most common usage. The "target URL" is the URL to which a hyperlink refers. The Croft Internet Draft [Page 3] [DRAFT] Telnet URL Transmission Option May 2000 "hyperlink text" is the descriptive text of the hyperlink itself and can be in any format. Once the two hosts have exchanged a WILL and a DO, the server is free to send URL information via a sub-negotiation at any time. It does so by sending a SEND-URL IS sub-negotiation containing the target URL, followed by the hyperlink text within the normal data stream. It then terminates the hyperlink by sending a SEND-URL END sub- negotiation. One may draw a parallel between the SEND-URL IS sub-negotiation and the HTML code , and between the SEND-URL END sub- negotiation and the HTML code . In both cases, the target URL is encoded within the initial "start hyperlink" command, and in both cases the hyperlink text itself appears within the normal stream of text. The URL information within the SEND-URL IS is an NVT ASCII string. If the character 255 occurs within this string, it must be doubled as specifed in the final sentence of [2]. The maximum permitted length of the URL sent is 1024 octets. [Unresolved issue: Have some mechanism for the client to inform the server of the maximum length permitted?] The format of the URL is specified in the "Uniform Resource Locators (URL)" RFC [3]. Relative URLs are not permitted. URLs must not be surrounded by quotation marks (""), although they will appear within them in the examples in this document in order to distinguish them as strings of text as opposed to single octets. The text sent between the SEND-URL IS and SEND-URL END sub- negotiations is referred to as the hyperlink text. The maximum permitted size of this text is 1024 characters. [Unresolved issue: is this necessary at all?] The client may send DONT at any time to instruct the server to stop sending URL information. The server must stop sending URL information immediately, and indicate its acceptance with WONT. The server may send WONT at any time to inform the client that it will no longer send URL information. The client must indicate its acceptance with a DONT. 6. Implementation Issues Care must be taken to prevent non-terminating loops of option negotiations. Your attention is directed towards the advice in [1] Croft Internet Draft [Page 4] [DRAFT] Telnet URL Transmission Option May 2000 and [4]. If the client receives WONT (i.e. the server will no longer send URL information), and it appears that the server is in the middle of a hyperlink (i.e. a SEND-URL IS has been received, but no corresponding SEND-URL END has been received), then the client must assume that the hyperlink ends at that point, just as if a SEND-URL END had been received. The server must record whether it has sent a SEND-URL IS, and be sure to terminate the hyperlink using SEND-URL END before it begins a new hyperlink. However, the client must be prepared for a broken server implementation which sends the sub-negotiations out of sequence. In the event that the client receives a SEND-URL IS without the previous hyperlink being terminated, the client must assume that the previous hyperlink text ends at that point, and begin immediately processing the new hyperlink. In the event that the client receives a SEND-URL END whilst not processing a hyperlink, it should do nothing. In the event that the server sends the Telnet "Synch" signal, as defined on pages 8-10 of [1], and the client reaches the Data Mark still believing a hyperlink to be in progress, the client must assume that the hyperlink ends immediately, as if SEND-URL END had been sent along with the data mark. [ Unresolved issue: Should this instead follow RFC728's second solution and have the server itself actually send a SEND-URL END after the data mark? This is probably not sensible since (a) it may send a SEND-URL END out of sync and (b) the client/server may not be in a DO/WILL state at the point of the data mark? ] The client must be prepared for the hyperlink text to be longer than 1024 characters. In this case it must assume the hyperlink ends after the 1024th character. The server must never send target URLs longer than 1024 characters. In the event that the client receives a URL longer than this, it should skip through the data stream searching for the end of the subnegotiation (IAC SE). It should then disregard the entire subnegotiation, as a truncated URL is unlikely to be valid. If the client has refused to accept URL information, by sending DONT SEND-URL, then the server must not attempt to send WILL SEND-URL again unless something has changed. It must not, for example, attempt to renegotiate WILL SEND-URL every time it wants to send a URL. This is to prevent non-terminating request loops as discussed in the "General Considerations" section of the Telnet Protocol Specification [1]. Croft Internet Draft [Page 5] [DRAFT] Telnet URL Transmission Option May 2000 An indication that you will accept URL information (by sending DO SEND-URL) does not in itself allow you to send URL information. If you wish to do this, you must negotiate separately (by sending WILL SEND-URL). Be aware that some applications will only allow URL information in one direction, so your request may be denied. How received URLs are handled is entirely up to the program receiving them. Here are a few examples of how URLs could be handled: A graphical client could underline the hyperlink text, and allow the user to click on it to launch the URL. Alternatively, it could have a separate window available, showing the URLs received for the user to browse. A text-based client could store the most recent URLs, allowing the user to launch them perhaps using the client's command mode. Or, it could automatically save such URLs into a "bookmark" file for the user to browse at his/her leisure. It is highly recommended that programs do not automatically launch URLs, but that they should require user interaction to do so. 7. Examples In this example, the client refuses to accept URL information from the server, either because it does not understand the option, or because it does not wish to receive such information. Server: IAC WILL SEND-URL Client: IAC DONT SEND-URL (The default state of WONT, DONT is thus maintained.) In this example, the client indicates it can accept URL information and the server then sends a URL to the client. Server: IAC WILL SEND-URL Client: IAC DO SEND-URL (Server may now send URL information at any time.) Server: "go to " IAC SB SEND-URL IS "http://www.yahoo.com/" IAC SE "Yahoo!" IAC SB SEND-URL END IAC SE " for more info..." (The server indicates that the text "Yahoo!" is to be treated Croft Internet Draft [Page 6] [DRAFT] Telnet URL Transmission Option May 2000 as a hyperlink to target "http://www.yahoo.com/".) (One may imagine this as a piece of HTML code reading go to Yahoo! for more info...) 8. Security Considerations Security issues are not discussed in this memo. Attention is drawn to the maximum length requirements in section 5, and the advice at the end of section 6 that clients should not automatically launch URLs. 9. References: [1] Postel, J., and J. Reynolds, "Telnet Protocol Specification", RFC 854, USC Information Sciences Institute, May 1983. [2] Postel, J., and J. Reynolds, "Telnet Option Specification", RFC 855, USC Information Sciences Institute, May 1983. [3] Berners-Lee, T., L. Masinter, and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox PARC and University of Minnesota, December 1994. [4] Bernstein, D., "The Q Method of Implementing TELNET Option Negotiation" RFC 1143, NYU, February 1990. [5] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, Harvard University, October 1996. 10. Author's Address David Croft Infotrek Inchfield The Way Reigate Surrey RH2 0LD United Kingdom Phone: +44 7802 333066 Fax: +44 870 0557676 Email: david@infotrek.co.uk 11. Full Copyright Statement Croft Internet Draft [Page 7] [DRAFT] Telnet URL Transmission Option May 2000 Copyright (C) The Internet Society (2000). 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 implmentation 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." INTERNET DRAFT EXPIRES NOVEMBER 2000 INTERNET DRAFT Croft Internet Draft [Page 8]