<?xml version='1.0' encoding='UTF-8'?>

<!DOCTYPE helpdoc SYSTEM 'helpdoc.dtd'>
<helpdoc>
<title>Controlling access to your channel</title>
	<version type="revision" major="1" minor="1" point="3">

	<author>
<name>FredFred</name>
<email>Fredfred@dal.net</email>
</author>
<date>2005-10-26</date>
</version>
	<version type="revision" major="1" minor="1" point="2">

	<author>
<name>PJKevin</name>
<email>kevinram_2002@hotmail.com</email>
</author>
<date>2004-08-06</date>
</version>

	<version type="revision" major="1" minor="1" point="1">

	<author>
<name>quen</name>
<!-- Edited by Wizzu -->
<email>quen@leafdigital.com</email>
</author>
<date>2000-11-05</date>
</version>

	<version type="revision" major="1" minor="1" point="0">

	<author>
<name>quen</name>
<!-- Edited by Wizzu -->
<email>quen@leafdigital.com</email>
</author>
<date>2000-10-22</date>
</version>

	<version type="original" major="1" minor="0" point="0">

	<author>
<name>quen</name>
<!-- Edited by Wizzu -->
<email>quen@leafdigital.com</email>
</author>
<date>1997-06-20</date>
</version>

	<introduction>

	<section>
<title>Introduction</title>

	<p>

  This guide explains how to control who has access to certain privileges on
  your registered channel. These privileges are used to help maintain the
  channel's normal operation, so that other people (whom you trust) can
  keep order in the channel when you're not there.
</p>

	<p>
  
  This guide also explains how to ban people from the channel
  permanently using ChanServ. Bans that you set in the normal way will
  disappear if the channel becomes empty of people at any point.
</p>

	<p>

  If you haven't already registered your channel with ChanServ, you should
  first do that - read question 1.8 "How do I register my channel?"
  of the Services FAQ before continuing with this.
</p>

	<p>

  Finally, some brief notes - whenever I give a command to type such as
</p>

	<commandblock>

	<line>
/chanserv identify 
<param>#channel</param>
<param>password</param>
</line>
</commandblock>

	<p>

  The command should be typed as it is shown, 
<emphasis>except</emphasis>
 that you should replace 
  required parameters (here '#channel' and 'password') with the appropriate piece of information. 
  For instance, in the above example, if your password was 'apple' and your channel was   '#mychannel', you would actually type
</p>

	<commandblock>
<line>/chanserv identify #mychannel apple</line>
</commandblock>

	<p>

  When commands begin with 
<command>/chanserv</command>
 (or 
<command>/nickserv</command>
, 
<command>/memoserv</command>
), that is 
  an alias used to message the service securely. If your client does not understand the command,
  you can either begin the commands with 
<command>/quote chanserv</command>
, or with
  
<command>/msg chanserv@services.dal.net</command>
.
</p>
</section>
</introduction>

	<main>

	<section>
<title>Why you need to know this information</title>

	<p>
  
  DALnet encourages you to read this guide because:
</p>

	<list type="bullet">

	<item>

	<p>

    If your channel encounters problems such as abusive behaviour or a
    takeover, and you are not there, you will need AOPs and possibly
    SOPs so that the problem can be solved.
  
</p>
</item>

	<item>

	<p>

    If your channel becomes large, you may need SOPs to help manage it.
  
</p>
</item>

	<item>

	<p>

    Adding the wrong people as AOPs or SOPs, or adding AOPs or SOPs in
    the wrong way, can cause security loopholes that might let unfriendly
    users cause problems in the channel, so you should be fully informed
	about using these features.
  
</p>
</item>

	<item>

	<p>

    If you need permanent bans on users, you'll need to know how to set
    AKICKs.
  
</p>
</item>
</list>

	<p>
  
  A summary can be found in 
<crossref id="summary"/>
, which briefly explains who you
  should add as SOPs or AOPs and how to add them.
</p>
</section>

	<section>
<title>What AOPs and SOPs are</title>

	<p>
<definition>AOPs</definition>
 and 
<definition>SOPs</definition>
 are 
  people whom you trust enough to allow them certain powers on your channel.
</p>

	<p>
  
  SOPs are a "higher" level than AOPs and have all the AOP privileges in 
  addition to some extra powers. As the founder, you are at a higher level 
  still and you have all the SOP and AOP privileges, plus some founder-only
  powers. There is no need to add yourself to the SOP or AOP
  lists.
</p>

	<p>

  It's beyond the scope of this guide to give help on how to use all the
  ChanServ powers that are granted to AOPs and SOPs. However, by each
  ability the appropriate help command is given; typing this while on IRC
  will provide more information.
</p>
<p>
  AOPs have the following powers:
</p>

	<list type="bullet">

	<item>

	<p>

    They are given ops (@) when they enter the channel; if for some reason
    they are in the channel without ops, they can get ChanServ to give
    them ops at any time.
    (
<command>/chanserv help op</command>
)
  
</p>
</item>

	<item>

	<p>

    They can use ChanServ to give/remove ops to/from other members of the
    channel (if they do this, a notice will be sent to the channel
    alerting others on the channel of the action, so it is not anonymous).
    (
<command>/chanserv help op</command>
)
  
</p>
</item>

	<item>

	<p>

    They can unban themselves from the channel if they are banned.
    (
<command>/chanserv help unban</command>
)
  
</p>
</item>

	<item>

	<p>

    They receive memos that are sent to the whole 'channel'. They may also
    be able to send memos to the whole channel; there is a channel setting
    that determines whether AOPs, SOPs, or just the founder can send
    memos to the channel.
    (
<command>/chanserv help set memo</command>
, 
    
<command>/memoserv help send</command>
)
  
</p>
</item>

	<item>

	<p>

    It is possible to set channels so that only ops can change the topic.
    (However it's also possible to set them so that only SOPs or only the
    founder can change the topic.)
    (
<command>/chanserv help set topiclock</command>
)
  
</p>
</item>

	<item>

	<p>

    They can use the MDEOP commands to solve channel takeover problems, but
    this will not work if SOPs or the founder are on the channel.
    (
<command>/chanserv help mdeop</command>
)
  
</p>
</item>

	<item>

	<p>

    They can invite themselves to the channel (useful if it is
    invite-only) unless it has been set "private".
    (
<command>/chanserv help invite</command>
)
  
</p>
</item>

	<item>

	<p>

    They can view the channel AOP, SOP, and AKICK lists.
    (see 
<crossref id="aopsop"/>
)
  
</p>
</item>
</list>
<p>
  SOPs have the following additional powers:
</p>

	<list type="bullet">
	<item>

	<p>

    They can use the MKICK command to solve channel takeover problems, but
    this will not work if the founder is on the channel.
    (
<command>/chanserv help mkick</command>
)
    (see 
<crossref id="aopsop"/>
)
  
</p>
</item>
	<item>

	<p>

    They can give, and take away, AOP privileges from people.
    (see 
<crossref id="aopsop"/>
)
  
</p>
</item>

	<item>

	<p>

    They can set or remove AKICKs (permanent bans) for the channel.
    (see 
<crossref id="akick"/>
 and 
<crossref id="akickadd"/>
)
  
</p>
</item>

	<item>

	<p>

    They can remove 
<emphasis>all</emphasis>
 bans from the channel using ChanServ.
    (
<command>/chanserv help unban</command>
)
  
</p>
</item>

	<item>

	<p>

    They receive memos sent to channel SOPs.
    (
<command>/memoserv help sendsop</command>
)
  
</p>
</item>
</list>
</section>

	<section>

	<title>
Things to consider when giving AOP or SOP privileges
</title>

	<p>

  AOPs and SOPs are the people who can handle channel problems such as
  flooding and takeovers when you are not there. If you intend to run a
  successful channel, it is your reponsibility to ensure there are
  sufficient AOPs (especially) and SOPs so that order in the channel can
  be maintained. If the channel is being used with no AOPs present, then
  it is an easy target for flooding and abuse.
</p>

	<p>

  When you give people AOP or SOP privileges, you give them some control
  over the channel, but they are still answerable to you - you could
  remove the AOP or SOP privileges at any time. 
</p>

	<p>

  However, you should still make sure only to give AOPs or SOPs to people
  that you trust as they 
<emphasis>can</emphasis>
 cause problems. Although 
  they cannot do any permanent damage - the founder can undo any changes 
  they make - they can certainly cause serious problems especially when 
  you're not
  there. You should keep this in mind when giving AOP or SOP privileges. 
</p>

	<p>

  On a similar note: never give out the password to the channel to anyone. 
  This is the same as handing over the channel to them - co-founderships
  are not supported by DALnet and in a dispute, anybody with the password
  is considered the sole owner of the channel. If you want to share
  power on your channel with others who you trust, make them SOPs.
</p>

	<p>

  If a different arrangement is desirable, you can use socially agreed
  restrictions (for example, the founder might agree never to add SOPs 
  without consulting the existing SOPs). However DALnet's software and
  staff will always consider the founder of a channel to be the only
  person finally responsible for how that channel is run. And please note
  that DALnet will never help anyone who loses a channel because they 
  shared a password; passwords should always be kept secure.
</p>
</section>

	<section id="aopsop">
<title>How to add or remove AOPs and SOPs</title>

	<p>

  The channel founder is the only one who can give or take away SOP
  privileges. SOPs and the founder can give or take away AOP privileges.
  The two list commands are available to AOPs or SOPs and the founder, but not to
  ordinary users.
</p>

	<subsection>
<title>Listing current SOPs or AOPs</title>

	<commandblock>

	<line>
/chanserv sop 
<param>#channel</param>
 list
</line>

	<line>
/chanserv aop 
<param>#channel</param>
 list
</line>
</commandblock>

	<p>

    These commands list all the SOPs or AOPs (respectively) on the
    channel.
</p>

	<p>

    If you have a large channel, you may find it useful to list only 
	selected SOPs or AOPs based on their nicknames or masks:
</p>

	<commandblock>

	<line>
/chanserv sop 
<param>#channel</param>
 list 
<param>wildcard</param>
</line>

	<line>
/chanserv aop 
<param>#channel</param>
 list 
<param>wildcard</param>
</line>
</commandblock>

	<p>

    (For example, 
<command>/chanserv aop #mychannel list g*</command>
 would list
	all AOPs on #mychannel whose nicknames began with g.)
</p>

	<p>

    Whichever list command you use, each AOP or SOP is listed with a number which makes 
	it easier to remove them if necessary (see below).
</p>
</subsection>

	<subsection>
<title>Adding SOPs or AOPs</title>

	<commandblock>

	<line>
/chanserv sop 
<param>#channel</param>
 add 
<param>nick or mask</param>
</line>

	<line>
/chanserv aop 
<param>#channel</param>
 add 
<param>nick or mask</param>
</line>
</commandblock>

	<p>

    These commands add people to the SOP or AOP lists. This is equivalent
    to giving people SOP or AOP privileges.
</p>

	<p>

    Generally you should add AOPs or SOPs using their nick (which should
    be registered) but you can also do so with a mask if necessary. Masks
    work in the same way as channel ban masks - though of course here they
    have the effect of granting AOP or SOP privileges to the target, not
    banning them - and are not explained in this guide; for more
    information see the Ban Guide. 
</p>

	<p>

    If you want to make somebody an SOP who is currently an AOP (or vice versa), 
	you don't need to remove them from the AOP list, because Services will 
	automatically remove them for you at the same time as adding them to the
	SOP list.
</p>

	<p>

    You should check somebody has a registered nick before you give them
    AOPs by typing 
</p>

	<commandblock>

	<line>
/nickserv info 
<param>nick</param>
</line>
</commandblock>

	<p>

    and ask them to register if their nick isn't registered. If you try to
    add AOPs for somebody whose nick isn't registered, it will add them
    using a mask, which isn't really a good idea (see 
<crossref id="masks"/>
). 
</p>

	<p>

    Each channel is limited to a maximum of 300 AOPs and 100 SOPs. ChanServ will
	warn you if you attempt to add more than this.
</p>

	<p>

	Note: Users can set a nickname mode NOOP which will mean they
	can't be added to any channel AOP or SOP lists. See 
	
<command>/nickserv help set noop</command>
 for more information.
</p>
</subsection>

	<subsection>
<title>Removing SOPs or AOPs</title>

	<commandblock>

	<line>
/chanserv sop 
<param>#channel</param>
 del 
<param>number or entry in list</param>
</line>

	<line>
/chanserv aop 
<param>#channel</param>
 del 
<param>number or entry in list</param>
</line>
</commandblock>

	<p>

    These commands are used to remove people from the SOP or AOP lists. SOPs and AOPs may be removed for misconduct 
or for whatever the reason may be.
</p>

	<p>

    You can use these commands in several ways; the easiest is to first
    use the appropriate list command, and then give the number of the
    entry you want deleted. Alternatively, you can give the nick or the
    access mask you want deleted; if you use this method you must specify
    the nick or mask exactly as it is given in the list.
</p>

	<p>

    If you are deleting entries based on their numbers in the list, you 
	should only delete a single entry at a time. The numbers may change
	after each deletion, so you will need to repeat the list command to check
	what the correct number is.
</p>
</subsection>

	<subsection>
<title>VERBOSE mode</title>

	<p>

    If the VERBOSE mode is turned on for a channel, then whenever there is 
	a change to certain aspects of the channel (in particularly, when somebody
	adds or removes AOP/SOPs or AKICKs), all ops currently on the channel will be
	informed with a notice.
</p>
<p>
    To enable this feature:
</p>

	<commandblock>

	<line>
/chanserv set 
<param>#channel</param>
 verbose on
</line>
</commandblock>
</subsection>
</section>

	<section id="masks">

	<title>
Advice on using address masks in your AOP/SOP lists
</title>

	<p>

  It's generally best to use nicknames, rather than address masks, in
  AOP/SOP lists. There are several reasons for this:
</p>

	<list type="bullet">

	<item>

	<p>

    You can always tell exactly who has AOPs or SOPs.
  
</p>
</item>

	<item>

	<p>

    It's not really possible to make a mistake and give lots more people
    AOPs than were intended (for example if you put a * in the wrong
    place in a mask.)
  
</p>
</item>

	<item>

	<p>

    If you encounter problems with somebody using the same server as an
    AOP and getting ops meant for the AOP, these can be solved without
    removing AOPs from the genuine person.
  
</p>
</item>
</list>
<p>
  There is one advantage to using address masks:
</p>

	<list type="bullet">

	<item>

	<p>

    You can always tell exactly what address masks will get ops
    automatically.  
  
</p>
</item>
</list>

	<p>

  If you do decide to use address masks to give AOPs, see the Ban Guide
  which explains address masks. 
</p>

	<p>

  Note that although that guide explains how to use them to ban people,
  when you use them on the AOP list they are not banned but given AOPs.
</p>
</section>

	<section id="masks">
<title>Problems with the wrong people getting AOPs/SOPs</title>

	<p>

  (Note: This section is written about AOPs, but all of it applies to SOPs
  as well.)
</p>

	<p>

  There are times you may find someone you did not add to the access list(s) gain access to the channel. The reason why this happens is because of the AOP or SOP's hostmask matches the one 
listed in the Op's NickServ's access list.
</p>

	<p>

  People can get 
<emphasis>ops</emphasis>
 in the channel (but not 
  access to any of
  the ChanServ AOP commands) if ChanServ is down and your channel is
  empty when they enter it. Unfortunately, there's nothing you can do
  about this, but ChanServ rarely stays down for more than a few minutes.
</p>

	<p>

  People can also get ops if they are given them by somebody
  who already has ops (e.g. an AOP or SOP). If you do not want to allow this,
  you can use a feature called OPGUARD which is explained at the end of this
  section.
</p>

	<subsection>
<title>Finding out why somebody has privileges</title>

	<p>

  To discover why somebody has AOP or SOP privileges in a channel, you can
  use the ChanServ 
<command>why</command>
 command:
</p>

	<commandblock>

	<line>
/chanserv why 
<param>#channel</param>
<param>nickname</param>
</line>
</commandblock>

	<p>

  This will explain the AOP or SOP list entry (if any) that is responsible
  for granting that person privileges, so it can be temporarily removed if
  there is a problem.
</p>
</subsection>

	<subsection>
<title>Access list problems</title>

	<p>

  When you have people added to your AOP list by nickname, this means
  that anybody matching the 'access list' of any of your AOPs will get
  AOP privileges in the channel.
</p>

	<p>

  If people who aren't AOPs get opped by ChanServ on the channel, there
  may well be a problem with access lists - you can normally tell which
  AOP's list is the problem because the non-AOP who got opped will come
  from the same service provider (eg aol.com, netcom.com, iquest.net,
  etc.) as one of your AOPs. You can confirm this with the 
<command>why</command>

  command given above.
</p>

	<p>

  You should contact the AOP (by memo if they are not online) suggesting
  that they improve their access list or remove it entirely, identifying
  to NickServ with their password when they log on to DALnet. In the
  meantime, if the person who has ops is causing trouble you may want to
  temporarily remove the relevant AOP privileges.
</p>

	<p>

  If you or they don't fully understand the concept of NickServ access
  lists - which allow you to use your nickname on DALnet without giving
  the password every time, but introduce security weaknesses if you use
  a major Internet service provider - then the NickServ Access Guide
  contains the explanation you need.
</p>

	<p>

  You've probably realised by now that a malicious AOP could intentionally
  set their access list to, for instance, allow 
<emphasis>everybody</emphasis>
 ops on the
  channel. This is another reason for making sure you trust people before
  you give them AOPs.
</p>

	<p>

  As a temporary solution if there is a problem with access masks, or if
  security needs to be high, you can set IDENT mode on for the channel.
  This means that ChanServ will only allow those AOPs who've also
  identified to NickServ (with the password for their nick) access to
  their privileges on the channel, including ops.
</p>

	<p>

  The founder can set IDENT mode for a channel using
</p>

	<commandblock>

	<line>
/chanserv set 
<param>#channel</param>
 ident on
</line>
</commandblock>

	<p>

  Note that if you do this, any entries using masks rather than nicknames
  will not have any effect. For more information:
</p>

	<commandblock>
<line>/chanserv help set ident</line>
</commandblock>
</subsection>

	<subsection>
<title>Unwanted ops</title>

	<p>

    Even when ChanServ manages a channel, it is possible that some people who are not AOPs
	or SOPs might get ops (@) in that channel. The main way this can happen is if an AOP gives
	them ops.
</p>

	<p>

    If you as channel founder do not want this to happen, you can enable the OPGUARD feature.
	When this feature is turned on, ChanServ will not allow people to have ops (@) on a channel
	(even temporarily) unless they are on the AOP or SOP list or are the founder. If somebody
	else is given ops, ChanServ will remove their ops immediately.
</p>
<p>
    To enable this feature:
</p>

	<commandblock>

	<line>
/chanserv set 
<param>#channel</param>
 opguard on
</line>
</commandblock>
</subsection>
</section>

	<section id="akick">
<title>What AKICKs are</title>

	<p>

  AKICKs are the ChanServ equivalent of a ban from the channel and are
  used to remove offending users from your channel. They do not disappear
  if the channel becomes empty; they stay until the channel founder or SOP
  removes them.
</p>

	<p>

  The key problem with standard channel bans (the sort you get
  when you click the 'Ban' option on popup menus, or type 
<command>/ban</command>
 
  or 

	<command>
/mode 
<param>#channel</param>
 +b 
<param>mask</param>
</command>
 
  commands) is that these are temporary; if everybody leaves the channel so that
  it's empty, the system 'forgets' all the normal bans that were set.
</p>

	<p>

  Normally bans are set to deal with temporary nuisances so this is not a
  problem. However, sometimes you can encounter problems with a user who
  continually comes to the channel to cause problems - in this case, you
  need to ban them permanently.
</p>

	<p>

  In this situation you use AKICKs, which work similarly to bans but  
  are handled by Services - when a user on the AKICK list enters a
  channel, they are automatically banned and kicked out by ChanServ. As
  mentioned above, AKICKs don't disappear until they are removed, even if  
  the channel becomes empty.
</p>
</section>

	<section id="akickadd">
<title>How to add or remove AKICKs</title>

	<p>

  Only channel founders and SOPs have the power to add or remove AKICKs.
</p>

	<subsection>
<title>Listing current AKICKs</title>

	<commandblock>

	<line>
/chanserv akick 
<param>#channel</param>
 list
</line>
</commandblock>

	<p>

    This command, which can be used by channel AOPs as well as SOPs and
    the founder, lists all of the AKICKs currently in place on
    the channel.
</p>

	<p>

    Each AKICK is listed together with a number which you can use to
    remove it more easily.
</p>
</subsection>

	<subsection>
<title>Adding an AKICK by mask</title>

	<commandblock>

	<line>
/chanserv akick 
<param>#channel</param>
 add 
<param>mask</param>
</line>
</commandblock>

	<p>

    This command adds an AKICK to the channel. You must specify the user's 
    mask in the same way as for a ban - 
	

	<command>
<param>nickname</param>
!
<param>username</param>
@
<param>hostname</param>
</command>
.
</p>

	<p>

    If the address in 
<command>/whois</command>
 of a user you were trying to ban was 
    
<response>user@dialup22-81.provider.com</response>

    and your channel was called #frogs, you would typically use
    
<command>/chanserv akick #frogs add *!user@*.provider.com</command>

    ('AKICK people with any nickname, if they have the username "user",
    and are coming from provider.com')
</p>

	<p>

    For more guidance on address masks for bans, which work the same 
    way in AKICKs as in channel, please see the Ban Guide.
</p>

	<p>

    You can add a maximum of 200 AKICKs for a single channel.
</p>
</subsection>

	<subsection>
<title>Adding an AKICK by nickname</title>

	<commandblock>

	<line>
/chanserv akick 
<param>#channel</param>
 add 
<param>nickname</param>
</line>
</commandblock>

	<p>

    If the person has a registered nickname, you can add an AKICK using their
    nick. This may or may not be useful because in some cases they can simply 
	connect with a different nickname to evade the ban. 
</p>

	<p>

    So if you don't understand address masks for bans, you can use this
    method instead, but it is more reliable to do it by manually
    specifying the mask.
</p>
</subsection>

	<subsection>
<title>Removing an AKICK</title>

	<commandblock>

	<line>
/chanserv akick 
<param>#channel</param>
 del 
<param>number or mask</param>
</line>
</commandblock>

	<p>

    You can use this commands in two ways; the easiest is to first
    use the list command (given above), and then give the number of the
    entry you want deleted. Alternatively, you can give the mask you want
    deleted; if you use this method you must specify the mask exactly as
    it is given in the list.
</p>

	<p>

    If you are deleting entries based on their numbers in the list, you 
	should only delete a single entry at a time. The numbers may change
	after each deletion, so you will need to repeat the list command to check
	what the correct number is.
</p>
</subsection>
</section>

	<section id="summary">
<title>Summary</title>

	<p>

  SOPs and AOPs are people you trust enough to give them some power on
  your channel. Among other things, this means that they will
  automatically be given ops (@) when they enter. SOPs also have the
  ability to add and remove AOPs and AKICKs (permanent bans from the
  channel), so you should be especially careful when making people SOPs.
</p>

	<list type="text">

	<item>

	<title>
If there is somebody you trust whom you think should have AOPs on your
  channel
</title>

	<p>
Type 

	<command>
/nickserv info 
<param>nick</param>
</command>

  to check their nick is registered - if it is not, ask them to register
  it and repeat the above when they've done so. Once you're sure the
  nickname is registered, type 

	<command>
/chanserv aop 
<param>#channel</param>
 
  add 
<param>nick</param>
</command>
.
</p>
</item>

	<item>

	<title>
If your channel needs an SOP for some reason - for instance if it is a
  large channel and you need help with channel management such as choosing
  AOPs
</title>

	<p>
Be certain you can trust the person you'd like to make an
  SOP, and check their nick is registered as above. Then type
  

	<command>
/chanserv sop 
<param>#channel</param>
 add 
<param>nick</param>
</command>
.
</p>
</item>

	<item>

	<title>
If at a later date you need to remove an AOP or SOP from the channel
  list because they have proven untrustworthy, left IRC, or similar
</title>

	<p>
Type 

	<command>
/chanserv 
<param>aop or sop</param>
<param>#channel</param>
 
  list
</command>
. When you find the entry for that person, you should note the 
  number and type 

	<command>
/chanserv 
<param>aop or sop</param>
<param>#channel</param>
 
  del 
<param>number</param>
</command>
.
</p>
</item>

	<item>
<title>If you need to ban somebody permanently</title>

	<p>
You (or an SOP on the channel; not AOPs) can add them to the AKICK list by using
  

	<command>
/chanserv akick 
<param>#channel</param>
 add 
<param>mask</param>
</command>
,
  where 

	<command>
<param>mask</param>
</command>
 is a standard ban mask for the 
  troublemaker. You can remove AKICKs at a later date in a similar way to removing 
  AOPs or SOPs. (See 
<crossref id="akickadd"/>
.)
</p>
</item>
</list>
</section>
</main>
</helpdoc>