--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+ <HEAD>
+ <TITLE> [IRCServices] Desired behavior of channel suspension?
+ </TITLE>
+ <LINK REL="Index" HREF="index.html" >
+ <LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20Desired%20behavior%20of%20channel%20suspension%3F&In-Reply-To=">
+ <META NAME="robots" CONTENT="index,nofollow">
+ <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
+ <LINK REL="Previous" HREF="001071.html">
+ <LINK REL="Next" HREF="001073.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[IRCServices] Desired behavior of channel suspension?</H1>
+ <B>&quot</B>
+ <A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20Desired%20behavior%20of%20channel%20suspension%3F&In-Reply-To="
+ TITLE="[IRCServices] Desired behavior of channel suspension?">&quot
+ </A><BR>
+ <I>Sat Jan 13 04:37:06 PST 2001</I>
+ <P><UL>
+ <LI>Previous message: <A HREF="001071.html">[IRCServices] IRCServices-4.5.0 Release Date?
+</A></li>
+ <LI>Next message: <A HREF="001073.html">[IRCServices] IRCServices 4.5.0 ?
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#1072">[ date ]</a>
+ <a href="thread.html#1072">[ thread ]</a>
+ <a href="subject.html#1072">[ subject ]</a>
+ <a href="author.html#1072">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>[snip]
+Sorry about my late (and probably useless) reply...
+
+><i> One of the features going into 4.5.0 will be channel suspension.
+</I>><i> However, there are a number of potential issues as to how a suspended
+</I>><i> channel should be treated, so I'd like to gather opinions on the
+</I>><i> following points: (my current thoughts are in [brackets])
+</I>><i>
+</I>><i> - Should a suspended channel be treated like a forbidden one (no
+</I>><i> one can enter it) or an unregistered one (it can be used, but Services
+</I>><i> won't do anything do it)? [forbidden]
+</I>><i>
+</I>I'd agree with forbidden here, but maybe a config file option to allow
+setting
+whether no-one can enter it or whether people can enter it, but Services
+just
+won't interract with the channel at all (as if it was unregistered).
+
+However, if you don't want Services to interract with a registered channel,
+wouldn't it just be a good idea to add an IGNORE command? Probably not the
+best idea, but this would allow you to just stop Services interracting with
+channels IF you decide to make SUSPEND disallow people going into the
+channel at all.
+
+><i> - Should Services allow changes to the channel settings? I think
+</I>><i> this one is a pretty clear "no", but I'll put it up for debate. [no]
+</I>><i>
+</I>No, if it's suspended the only action you should be able to take against it
+as
+a Services Admin would be to DROP the channel or make it unsuspended.
+
+><i> - Should Services allow the founder to drop the channel? The
+</I>><i> current behavior of suspended nicknames is that the owner cannot drop
+</I>><i> them, but this is only because the owner cannot identify for them and
+</I>><i> not because Services specifically prevents dropping; I could see
+</I>><i> suspended channels going either way. [undecided]
+</I>><i>
+</I>I'd say no, if a channel is suspended, only a Services Admin can DROP or
+unsuspend the channel in question. If you allow DROP to channel founder,
+then all they'd have
+to do is DROP it, then re-register it. In which case, you may as well
+forbid the channel because they'd DROP it, lose the access/akick lists 'n'
+such. They'd lose that on a FORBID anyhow.
+
+><i> - Should Services allow memos to be sent to the channel? [no]
+</I>><i> Incidentally, 4.4.x allows memos to be sent to suspended nicks; I'm
+</I>><i> planning on disabling that as well unless someone convinces me
+</I>><i> otherwise.
+</I>><i>
+</I>I'd agree here too, you can't send memos to a suspended nick.
+Obviously someone did something bad to warrant having their nick or channel
+suspended, so why should you give them the right to have memos sent or
+received.
+If a nick can't get memos, most people would re-register a new nick so they
+can or just to bypass the suspension of their old nick. So they COULD
+still get Memos then, unless you've had them AKILL'd in which case IMHO the
+suspension of their nick is pointless.
+
+Just my 0.2p's worth of input there.
+
+><i> --Andrew Church
+</I>><i> <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">achurch at achurch.org</A> | New address - please note.
+</I>><i> <A HREF="http://achurch.org/">http://achurch.org/</A> | \e$B%a!<%k%"%I%l%9$,JQ$o$j$^$7$?!#\e(B
+</I>><i>
+</I>><i> ---------------------------------------------------------------
+</I>><i> To unsubscribe, send email to <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">majordomo at snow.shadowfire.org</A>
+</I>><i> with "unsubscribe ircservices" in the body, without the quotes.
+</I>
+---------------------------------------------------------------
+To unsubscribe, send email to <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">majordomo at snow.shadowfire.org</A>
+with "unsubscribe ircservices" in the body, without the quotes.
+
+
+</PRE>
+
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+ <LI>Previous message: <A HREF="001071.html">[IRCServices] IRCServices-4.5.0 Release Date?
+</A></li>
+ <LI>Next message: <A HREF="001073.html">[IRCServices] IRCServices 4.5.0 ?
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#1072">[ date ]</a>
+ <a href="thread.html#1072">[ thread ]</a>
+ <a href="subject.html#1072">[ subject ]</a>
+ <a href="author.html#1072">[ author ]</a>
+ </LI>
+ </UL>
+
+</body></html>
projects / irc.git / blobdiff