57235 - Need to update, correct, and submit irc url handler to W3C/IETF.

Status: RESOLVED WONTFIX

(Core :: Networking, defect, P3)

Description

[David Krause]

http://www.w3.org/Addressing/draft-mirashi-url-irc-01.txt

Splitoff from bug 28649.  Timeless and I had talked about writing up a corrected
version of this but nothing ever happened, so now we at least have a bug to
track it.  I'm assigning this to nobody, because I'm not sure who has time to
work on this right now.  Feel free to assign to yourself.

This draft expired on February 28, 1997, but I've looked around and haven't seen
anything newer.  There are several problems with it as timeless states below:

------- Additional Comments From [e-mail] 2000-05-24 07:06 -------
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/[e-mail] or
irc://irc.undernet.org/@[e-mail]#macintosh
or
irc://irc.undernet.org/=[e-mail] 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.

Comment 1

[Garth Wallace]

I agree with timeless. The RFC claims that the encoded form of # is omitted from
targets of type <chstring>, but there is no way of differentiating between
different channels with the same name but different prefixes that way. Consider
three channels: #example !example and #!example . All are legitimate channels
(at least on servers that support !channels), but how do you determine what is
meant by irc://irc.example.com/example or irc://irc.example.com/!example ? The
former apparently is assumed to be #example, but does the latter refer to
!example or #!example ? If it refers to #!example, how do you refer to !example ?

The RFC is buggy, clumsy, and unclear.

Comment 2

[Robert Ginda]

The way to distinguish is to add the OPTIONAL leading character, encoded.
See <http://www.mozilla.org/projects/rt-messaging/chatzilla/irc-urls.html>.

Comment 3

[Garth Wallace]

Doesn't look like there's a way to get to !channels then. Since ! isn't one of
the listed characters that are considered channel-name leading characters, #
will always be attached.

Basically, I agree with timeless on that point: just because the escaped
character codes look funny and take three keystrokes isn't a good reason for
making them an exception.

I disagree, however, on listing multiple targets in a single URL. I think that
would be more cleanly handled by simply having multiple URLs. I mean, mailto:
URLs can only specify one mailbox, and http: URLs can't specify multiple pages,
why should irc: URLs be any different in that respect?

Comment 4

[Robert Ginda]

! channels are just an oversight, they need to be added.  The only "exception"
made is that if you don't specify one of the known prefix characters, # is
assumed.  This same exception is made by the /join command on many irc clients,
and I don't think it's all that unreasonable.

Comment 5

[Robert Ginda]

Getting this off the chatzilla bug list.

Comment 6

[David Krause]

Remove myself from QA.

Comment 7

[Philip Chee]

Sorry guys but I can't think of a better component to move this bug to. If only there were something like Core::Networking/Protocols/Misc or mozilla.org::Standards or TechEvang::W3C