Bug 136542 - gaim's IRC driver does not handle multiline messages gracefully
gaim's IRC driver does not handle multiline messages gracefully
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: gaim (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Warren Togami
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-20 16:45 EDT by Daniel Reed
Modified: 2008-05-06 20:01 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 20:01:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
low-level CTCP dequoter, new CTCP parser, inline CTCP dequoter (5.50 KB, patch)
2004-10-21 19:13 EDT, Daniel Reed
no flags Details | Diff
low-level CTCP dequoter, new CTCP parser, inline CTCP dequoter, second implementation (9.93 KB, patch)
2005-01-04 19:28 EST, Daniel Reed
no flags Details | Diff

  None (edit)
Description Daniel Reed 2004-10-20 16:45:39 EDT
User-Agent:       
Build Identifier: 

gaim's IRC driver does not handle multiline messages gracefully.

Reproducible: Always
Steps to Reproduce:
1. Join a gaim IRC client to #test
2. Join a naim IRC client to #test
3. Paste more than one line of text into the naim client and witness the gaim client

Actual Results:  
gaim renders the multiline delimiter literally, as *r*n where * is a special
graphic denoting the hexadecimal value of the CTCP escape character (x0010):

<n> This is a first line*r*nThis is a second line.
<n> This is a second message.

Expected Results:  
gaim should render the embedded newline in a pleasing way, such as:
<n> This is a first line
    This is a second line.
<n> This is a second message.

[http://www.irchelp.org/irchelp/rfc/ctcpspec.html]

*****************
LOW LEVEL QUOTING
*****************

Even though messages to and from IRC servers cannot contain NUL, NL,
or CR, it still might be desirable to send ANY character (in so called
"middle level messages") between clients. In order for this to be
possible, those three characters have to be quoted. Therefore a quote
character is needed. Of course, the quote character itself has to be
quoted too, since it is in-band.

	M-QUOTE	::= '\020'

(Ie a CNTRL/P).

When sending a middle level message, if there is a character in the
set { NUL, NL, CR, M-QUOTE } present in the message, that character is
replaced by a two character sequence according to the following table:

	NUL	--> M-QUOTE '0'
	NL	--> M-QUOTE 'n'
	CR	--> M-QUOTE 'r'
	M-QUOTE	--> M-QUOTE M-QUOTE

When receiving a low level message, if there is a M-QUOTE, look at the
next character, and replace those two according to the following table
to get the corresponding middle level message:

	M-QUOTE '0'	--> NUL
	M-QUOTE 'n'	--> NL
	M-QUOTE 'r'	--> CR
	M-QUOTE M-QUOTE	--> M-QUOTE

If the character following M-QUOTE is not any of the listed
characters, that is an error, so drop the M-QUOTE character from the
message, optionally warning the user about it. For example, a string
'x' M-QUOTE 'y' 'z' from a server dequotes into 'x 'y' 'z'.

 ...

- --- Example 1 -----------------------------------------------------------------

A user (called actor) wanting to send the string:

	Hi there!\nHow are you?

to user victim, i.e. a message where the user has entered an inline
newline (how this is done, if at all, differs from client to client),
will result internaly in the client in the command:

	PRIVMSG victim :Hi there!\nHow are you? \K?

which will be CTCP quoted into:

	PRIVMSG victim :Hi there!\nHow are you? \\K?

which in turn will be low level quoted into:

	PRIVMSG victim :Hi there!\020nHow are you? \\K?

and sent to the server after appending a newline at the end.

This will arrive on victim's side as:

	:actor PRIVMSG victim :Hi there!\020nHow are you? \\K?

(where the \\K would look similar to OK in SIS D47 et. al.) which after
low level dequoting becomes:

	:actor PRIVMSG victim :Hi there!\nHow are you? \\K?

and after CTCP dequoting:

	:actom PRIVMSG victim :Hi there!\nHow are you? \K?

How this is displayed differs from client to client, but it suggested
that a line break should occour between the words "there" and "How".
Comment 1 Luke Schierer 2004-10-20 16:49:18 EDT
the irc protocol doesn't allow multi-line comments. i'd argue that
sending multiple messages is the correct, and more readable than
embeding a literal \n in the message. 
Comment 2 Ethan Blanton 2004-10-20 17:25:59 EDT
This report is valid, although it is not a bug report, it is an RFE. 
I tried to mark it as such, but I cannot.  I thought we had CTCP
quoting at one time, but it appears we indeed do not.  I'll put that
on the list of things to tackle, but it's not a high priority.  To
quote what I apparently said when I wrote the current CTCP parser:

	/* Note that this is NOT correct w.r.t. multiple CTCPs in one
	 * message and low-level quoting ... but if you want that crap,
	 * use a real IRC client. */

The current implementation doesn't do anything incorrect, I should
point out, it simply does not implement all of CTCP.  As CTCP is not
core IRC (and, in fact, not even standardized in any real way), I
don't see this as a huge deal.  I swear, CTCP and DCC were designed by
gradeschool kids.

Ethan
Comment 3 Daniel Reed 2004-10-20 17:27:28 EDT
The IRC protocol does not disallow the concept of multiline messages, nor does
it have requirements that make it impossible to implement. The CTCP
specification, published circa 1991, includes one possible way to implement
multiline messages: By quoting newlines with a special delimiter.

The message:
  Hi there!\nHow are you?
becomes:
  Hi there!\020nHow are you?
which is sent to the server as:
  PRIVMSG victim :Hi there!\020nHow are you?\r\n

A client that receives the character \020 as part of a message is expected to
examine the next character. \020r should be treated as \r; \020n should be
treated as \n; \020\020 should be treated as a literal \020; and \0200 should be
treated as \0. This bug is filed because gaim does not dequote \020r and \020n
as \r and \n (resp.). What it would do with those characters is not the issue: I
would be fine with gaim simply treating embedded newlines as spaces, but I would
prefer if gaim could be made to treat an embedded newline the same way it treats
a <br> in its AIM/ICQ mode. However, the end result should be that only the
sequence \020\020 would be rendered as the special * character (showing 0010).

Thanks.
Comment 4 Daniel Reed 2004-10-21 19:13:19 EDT
Created attachment 105616 [details]
low-level CTCP dequoter, new CTCP parser, inline CTCP dequoter

This seems to work for me. To test the specific functionality, sign on to an
IRC server in gaim, then telnet to the IRC server on port 6667. If you are
signed on as "victim" in gaim, type the following in telnet:

PRIVMSG victim :line^AVERSION^A 1^Pr^Pnline ^APING 1234^A2

It should show up as a CTCP request VERSION, a CTCP request PING 1234, and a
two-line message:
<actor> line 1
line 2

It may be important add two more components: One part to keep stacked CTCP
requests from causing you to send multiple replies, and one part to keep users
from being able to spoof messages (such as preventing multiline messages from
entering text into the left-most column).
Comment 5 Daniel Reed 2004-10-29 15:41:54 EDT
Is this patch acceptable for the short term? (Can I include it in our packages
until the functionality is available in a release?)
Comment 6 Daniel Reed 2004-12-16 15:48:38 EST
The current release (1.1.0) still does not appear to handle embedded newlines
gracefully. Is there an alternate patch in the works, or can I feel free to turn
my original patch (attachment 105616 [details]) on for our builds?
Comment 7 Daniel Reed 2005-01-04 19:28:49 EST
Created attachment 109351 [details]
low-level CTCP dequoter, new CTCP parser, inline CTCP dequoter, second implementation
Comment 8 Warren Togami 2005-04-29 01:40:53 EDT
Upstream said they would rewrite this in a different way a while ago, are they
still planning on doing so, or should we close this as WONTFIX?
Comment 9 Warren Togami 2005-09-11 06:46:38 EDT
Upstream still wishes to rewrite this capability for future inclusion?  FWIW
xchat has had this for a while now.  If upstream dislikes this capability then
please say so, so we can close this WONTFIX.
Comment 10 Warren Togami 2005-12-13 16:37:52 EST
ping upstream
Comment 11 John Thacker 2006-10-30 10:50:03 EST
upstream is still the same, even in the 2.0.0 betas.
Comment 12 Bug Zapper 2008-04-03 11:42:43 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 13 Bug Zapper 2008-05-06 20:01:46 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

Note You need to log in before you can comment on or make changes to this bug.