Internet DRAFT - draft-croft-telnet-url-trans
draft-croft-telnet-url-trans
INTERNET DRAFT EXPIRES NOVEMBER 2000 INTERNET DRAFT
Network Working Group D. Croft
Internet Draft Infotrek
May 2000
Telnet URL Transmission Option
<draft-croft-telnet-url-trans-00.txt>
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 <a href="...">, and between the SEND-URL END sub-
negotiation and the HTML code </a>. 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 <a href="http://www.yahoo.com/">Yahoo!</a> 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]
