Implement irc:// protocol handler

VERIFIED FIXED in Future

Status

Other Applications
ChatZilla
P3
enhancement
VERIFIED FIXED
18 years ago
14 years ago

People

(Reporter: BenB, Assigned: Robert Ginda)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
Currently, servers are hard-coded in initHost
<http://lxr.mozilla.org/seamonkey/source/extensions/irc/xul/content/static.js#112>.
If ChatZilla were invokable with "irc://host[/#channel]"-style URLs, servers
could be stored in bookmarks.
(Reporter)

Updated

18 years ago
Severity: normal → enhancement
(Assignee)

Comment 1

18 years ago
I'll take a look at bryner's finger: handler when I get the chance.  Feel free
to work up a patch :)
Status: NEW → ASSIGNED
(Reporter)

Comment 2

18 years ago
rginda, I propably won't fix this :-), but I have a URI-spec-draft for you:
<http://bugzilla.mozilla.org/show_bug.cgi?id=28649>
(Reporter)

Comment 3

18 years ago
Now, that was nonsense. Here'S the correct URL:
<http://www.w3.org/Addressing/draft-mirashi-url-irc-01.txt>

Comment 4

18 years ago
If I don't get around to complaining about that RFC would someone please send 
them this bug?

that RFC is buggy!
the following will fail miserably:
<blockquote>
      irc://foobar.org:6665/secret,needkey

    references the IRC channel secret on server foobar.org. The
    connection takes place over port 6665, and the user is prompted
    for a channel key in order to reference the channel.  
</blockquote>
It is ambiguous and messy. Saying that they will omit # & + because they need 
to be encoded:
<blockquote>
      Since most IRC channels begin with the '#' character which is 
      unsafe in a URL, it must be encoded. To avoid the cumbersome
      % encoding for most references, this draft omits the specific 
      mention of a channel prefix in a <target> of type <chstring>. 
      irc: URL scheme implementors must maintain a prefix variable (by 
      default, '#', with '&' and '+' as other allowable values) to form
      channel names in accordance with RFC 1459. Further, the characters
      '!', ',', ':' and '@' are reserved in the irc: URL scheme and must
      also be encoded.
</blockquote>
is not a good reason for omitting them in the RFC.

irc://irc.undernet.org/#macintosh
irc://irc.erols.com/&macintosh
these are both channels, irc.undernet.org can resolve to irc.erols.com
but #macintosh and &macintosh are not equivalent.
users should be , separated
irc://irc.mozilla.org/qabot#qa,techbot1,techbot2#mozbot would be a reasonable 
URL. It could mean qabot in #qa; techbot1 and techbot2 in #mozbot on 
irc.mozilla.org
and 
irc://irc.undernet.org/timeless#macintosh,chatzilla&chatzilla would also be 
valid. It could mean timeless on #macintosh and chatzilla on &chatzilla

irc://irc.mozilla.org/@qabot#qa could mean the user qabot that is @#qa
irc://irc.mozilla.org/+techbot1#qa could mean the user techbot1 that is +#qa

: is also illegal in nicks.
irc://newuser!identa%pass,moznewuser!identb%passb,chatnewuser!identc%passc@irc.
mozilla.org:6667/@mozbot#mozilla could mean connect as newuser [fall back to 
moznewuser and then chatnewuser], and look for mozbot @#mozilla

excuse the fact that these nicks are mostly real and that these channels mostly 
exist. also excuse the fact that most people don't visit &channels, but you 
can't exclude them from the URL spec just because.

dcc chat can also be described using =victim
irc://irc.undernet.org/=X
the only thing I haven't described [that i can think of] is fully qualified 
names, thankfully nothing above precludes the following

irc://irc.undernet.org/X@channels.undernet.org
or
irc://irc.undernet.org/@X@channels.undernet.org#macintosh
or
irc://irc.undernet.org/=X@channels.undernet.org
these would describe fully qualified addressing.

The fact that a channel has modes like +k do not seem to affect a url, but if 
people feel a need, then maybe:
irc://localhost/#evil%keyphrase

If anyone feels that i've omited any important pieces feel free to respond

I do not object to irc://irc.erols.com:6666/ as it is logical.
I do think that irc://irc.undernet.org should be valid, just like 
http://www.w3.org is valid.

This comment should be cleaned up before being presented as an rfc.

<nick>=<nickname>[!<ident>]
<nicknames>=<nick>[,<nicklist>]
<fullnick>=<nick>[@<nickhost>]|!<ident>@<nickhost>
<nicklist>=<fullnick>[,<nicklist>]
<nickstatus>=[@][+]<nick>
<nickslist>=<nickstatus>[,<nickslist>]
<channel>=[#|&|+]<string>
<nickcontactlist>=(<nick>|=<nick>)[,<nicklist>]
<channeldetails>=[<nicklist>]<channel>[%[<pass>]][,<channeldetails>]
<ircserver>=<server>[:<port>]

I do not think that http:// or http:/// are valid urls
I don't think that irc:// or irc:/// should be either.
so instead of 
irc://[<nicknames>@<ircserver>|<nicklist>|<ircserver>][/<channeldetails><nickco
ntactlist>]
I recommend 
irc:[//[<nicknames>@<ircserver>|<nicklist>]<ircserver>[/[<channeldetails><nickc
ontactlist>]]
this URL is not responsible for selecting the appropriate transport, that is 
left to the clients [ipv4, ipv6 ...] nor the routing.
(Assignee)

Comment 5

18 years ago
mass marking chatzilla bugs future
Target Milestone: --- → Future

Comment 6

18 years ago
*MASS SPAM*

Changing QA contact on all open or unverified ChatZilla bugs to me, David
Krause, as I am now the QA contact for this component.
QA Contact: rginda → David

Updated

18 years ago
Depends on: 57235

Comment 7

18 years ago
*** Bug 58452 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Summary: Implement protocol handler → Implement irc:// protocol handler
(Reporter)

Comment 8

17 years ago
Note: This has been fixed , at least somewhat. Also see Protozilla for external
IRC clients.
(Assignee)

Comment 9

17 years ago
Marking this fixed.  I'll address any bugs in the implementation as they come up.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 10

17 years ago
Marking VERIFIED.

Thanks for fixing it. This is a really nice feature!

Comment 11

15 years ago
really marking VERIFIED.
Status: RESOLVED → VERIFIED
Product: Core → Other Applications
You need to log in before you can comment on or make changes to this bug.