 		/**
 		 * The resource portion of the JID.
 		 *
-		 * Ensure that the resourcepart of an XMPP address is at
-least one byte in length and at most 1023 bytes in length.
-		 *
-		 * The resourcepart of a JID is an optional identifier placed after the
-domainpart and separated from the latter by the ’/’ character. A
-resourcepart can modify either a &lt;localpart&#64;domainpart&gt; address or a
-mere &lt;domainpart&gt; address. Typically a resourcepart uniquely
-identifies a specific connection (e.g., a device or location) or
-object (e.g., an occupant in a multi-user chat room) belonging to the
-entity associated with an XMPP localpart at a domain (i.e.,
-&lt;localpart&#64;domainpart/resourcepart&gt;).
-A resourcepart MUST be formatted such that the Resourceprep profile
-of [STRINGPREP] can be applied without failing (see Appendix B).
-Before comparing two resourceparts, an application MUST first ensure
-that the Resourceprep profile has been applied to each identifier
-(the profile need not be applied each time a comparison is made, as
-long as it has been applied before comparison).
-A resourcepart MUST NOT be zero bytes in length and MUST NOT be more
-than 1023 bytes in length. This rule is to be enforced after any
-mapping or normalization resulting from application of the
-Resourceprep profile of stringprep (e.g., in Resourceprep some
-characters can be mapped to nothing, which might result in a string
-of zero length).
-Informational Note: For historical reasons, the term "resource
-identifier" is often used in XMPP to refer to the optional portion
-of an XMPP address that follows the domainpart and the "/"
-separator character; to help prevent confusion between an XMPP
-"resource identifier" and the meanings of "resource" and
-"identifier" provided in Section 1.1 of [URI], this specification
-uses the term "resourcepart" instead of "resource identifier" (as
-in RFC 3920).
-
-XMPP entities SHOULD consider resourceparts to be opaque strings and
-SHOULD NOT impute meaning to any given resourcepart. In particular:
-o Use of the ’/’ character as a separator between the domainpart and
-the resourcepart does not imply that XMPP addresses are
-hierarchical in the way that, say, HTTP addresses are
-hierarchical; thus for example an XMPP address of the form
-&lt;localpart&#64;domainpart/foo/bar&gt; does not identify a resource "bar"
-that exists below a resource "foo" in a hierarchy of resources
-associated with the entity "localpart&#64;domain".
-o The ’&#64;’ character is allowed in the resourcepart and is often used
-in the "nick" shown in XMPP chatrooms. For example, the JID
-&lt;room&#64;chat.example.com/user&#64;host&gt; describes an entity who is an
-occupant of the room &lt;room&#64;chat.example.com&gt; with an (asserted)
-nick of &lt;user&#64;host&gt;. However, chatroom services do not
-necessarily check such an asserted nick against the occupant’s
-real JID.
+		 * <p>Ensure that the resourcepart of an XMPP address is at
+		 * least one byte in length and at most 1023 bytes in length.</p>
+		 *
+		 * <p>The resourcepart of a JID is an optional identifier placed after the
+		 * domainpart and separated from the latter by the ’/’ character. A
+		 * resourcepart can modify either a &lt;localpart&#64;domainpart&gt; address or a
+		 * mere &lt;domainpart&gt; address. Typically a resourcepart uniquely
+		 * identifies a specific connection (e.g., a device or location) or
+		 * object (e.g., an occupant in a multi-user chat room) belonging to the
+		 * entity associated with an XMPP localpart at a domain (i.e.,
+		 * &lt;localpart&#64;domainpart/resourcepart&gt;).</p>
+		 *
+		 * <p>A resourcepart MUST be formatted such that the Resourceprep profile
+		 * of [STRINGPREP] can be applied without failing (see Appendix B).
+		 * Before comparing two resourceparts, an application MUST first ensure
+		 * that the Resourceprep profile has been applied to each identifier
+		 * (the profile need not be applied each time a comparison is made, as
+		 * long as it has been applied before comparison).</p>
+		 *
+		 * <p>A resourcepart MUST NOT be zero bytes in length and MUST NOT be more
+		 * than 1023 bytes in length. This rule is to be enforced after any
+		 * mapping or normalization resulting from application of the
+		 * Resourceprep profile of stringprep (e.g., in Resourceprep some
+		 * characters can be mapped to nothing, which might result in a string
+		 * of zero length).</p>
+		 *
+		 * <p>Informational Note: For historical reasons, the term "resource
+		 * identifier" is often used in XMPP to refer to the optional portion
+		 * of an XMPP address that follows the domainpart and the "/"
+		 * separator character; to help prevent confusion between an XMPP
+		 * "resource identifier" and the meanings of "resource" and
+		 * "identifier" provided in Section 1.1 of [URI], this specification
+		 * uses the term "resourcepart" instead of "resource identifier" (as
+		 * in RFC 3920).</p>
+		 *
+		 * <p>XMPP entities SHOULD consider resourceparts to be opaque strings and
+		 * SHOULD NOT impute meaning to any given resourcepart. In particular:</p>
+		 *
+		 * <ul>
+		 * <li>Use of the ’/’ character as a separator between the domainpart and
+		 * the resourcepart does not imply that XMPP addresses are
+		 * hierarchical in the way that, say, HTTP addresses are
+		 * hierarchical; thus for example an XMPP address of the form
+		 * &lt;localpart&#64;domainpart/foo/bar&gt; does not identify a resource "bar"
+		 * that exists below a resource "foo" in a hierarchy of resources
+		 * associated with the entity "localpart&#64;domain".</li>
+		 * <li>The ’&#64;’ character is allowed in the resourcepart and is often used
+		 * in the "nick" shown in XMPP chatrooms. For example, the JID
+		 * &lt;room&#64;chat.example.com/user&#64;host&gt; describes an entity who is an
+		 * occupant of the room &lt;room&#64;chat.example.com&gt; with an (asserted)
+		 * nick of &lt;user&#64;host&gt;. However, chatroom services do not
+		 * necessarily check such an asserted nick against the occupant’s
+		 * real JID.</li>
+		 * </ul>
+		 *
+		 * @see http://tools.ietf.org/html/rfc6122#section-2.4
 		 */
 		public function get resource():String
 		{

		/**
		 * The domain portion of the JID.
		 *
		 * Ensure that the domainpart of an XMPP address is at
least one byte in length and at most 1023 bytes in length, and
conforms to the underlying length limits of the DNS.
		 *
		 * The domainpart of a JID is that portion after the ’&#64;’ character (if
any) and before the ’/’ character (if any); it is the primary
identifier and is the only REQUIRED element of a JID (a mere
domainpart is a valid JID). Typically a domainpart identifies the
"home" server to which clients connect for XML routing and data
management functionality. However, it is not necessary for an XMPP
domainpart to identify an entity that provides core XMPP server
functionality (e.g., a domainpart can identify an entity such as a
multi-user chat service, a publish-subscribe service, or a user
directory).
The domainpart for every XMPP service MUST be a fully qualified
domain name (FQDN; see [DNS]), IPv4 address, IPv6 address, or
unqualified hostname (i.e., a text label that is resolvable on a
local network).
Interoperability Note: Domainparts that are IP addresses might not
be accepted by other services for the sake of server-to-server
communication, and domainparts that are unqualified hostnames
cannot be used on public networks because they are resolvable only
on a local network.
If the domainpart includes a final character considered to be a label
separator (dot) by [IDNA2003] or [DNS], this character MUST be
stripped from the domainpart before the JID of which it is a part is
used for the purpose of routing an XML stanza, comparing against
another JID, or constructing an [XMPP-URI]. In particular, the
character MUST be stripped before any other canonicalization steps
are taken, such as application of the [NAMEPREP] profile of
[STRINGPREP] or completion of the ToASCII operation as described in
[IDNA2003].
A domainpart consisting of a fully qualified domain name MUST be an
"internationalized domain name" as defined in [IDNA2003]; that is, it
MUST be "a domain name in which every label is an internationalized
label" and MUST follow the rules for construction of
internationalized domain names specified in [IDNA2003]. When
preparing a text label (consisting of a sequence of UTF-8 encoded
Unicode code points) for representation as an internationalized label
in the process of constructing an XMPP domainpart or comparing two
XMPP domainparts, an application MUST ensure that for each text label
it is possible to apply without failing the ToASCII operation
specified in [IDNA2003] with the UseSTD3ASCIIRules flag set (thus
forbidding ASCII code points other than letters, digits, and
hyphens). If the ToASCII operation can be applied without failing,
then the label is an internationalized label. (Note: The ToASCII
operation includes application of the [NAMEPREP] profile of
[STRINGPREP] and encoding using the algorithm specified in
[PUNYCODE]; for details, see [IDNA2003].) Although XMPP applications
do not communicate the output of the ToASCII operation (called an
"ACE label") over the wire, it MUST be possible to apply that
operation without failing to each internationalized label. If an
XMPP application receives as input an ACE label, it SHOULD convert
that ACE label to an internationalized label using the ToUnicode
operation (see [IDNA2003]) before including the label in an XMPP
domainpart that will be communicated over the wire on an XMPP network
(however, instead of converting the label, there are legitimate
reasons why an application might instead refuse the input altogether
and return an error to the entity that provided the offending data).
A domainpart MUST NOT be zero bytes in length and MUST NOT be more
than 1023 bytes in length. This rule is to be enforced after any
mapping or normalization resulting from application of the Nameprep
profile of stringprep (e.g., in Nameprep some characters can be
mapped to nothing, which might result in a string of zero length).
Naturally, the length limits of [DNS] apply, and nothing in this
document is to be interpreted as overriding those more fundamental
limits.
In the terms of IDNA2008 [IDNA-DEFS], the domainpart of a JID is a
"domain name slot".
		 */
		public function get domain():String
		{

		/**
		 * The localpart (used to be called 'node') portion of the JID.
		 *
		 * <p>Ensure that the localpart of an XMPP address is at
		 * least one byte in length and at most 1023 bytes in length.</p>
		 *
		 * <p>The localpart of a JID is an optional identifier placed before the
		 * domainpart and separated from the latter by the ’&#64;’ character.
		 * Typically a localpart uniquely identifies the entity requesting and
		 * using network access provided by a server (i.e., a local account),
		 * although it can also represent other kinds of entities (e.g., a chat
		 * room associated with a multi-user chat service). The entity
		 * represented by an XMPP localpart is addressed within the context of a
		 * specific domain (i.e., &lt;localpart&#64;domainpart&gt;).</p>
		 *
		 * <p>A localpart MUST be formatted such that the Nodeprep profile of
		 * [STRINGPREP] can be applied without failing (see Appendix A). Before
		 * comparing two localparts, an application MUST first ensure that the
		 * Nodeprep profile has been applied to each identifier (the profile
		 * need not be applied each time a comparison is made, as long as it has
		 * been applied before comparison).</p>
		 *
		 * <p>A localpart MUST NOT be zero bytes in length and MUST NOT be more
		 * than 1023 bytes in length. This rule is to be enforced after any
		 * mapping or normalization resulting from application of the Nodeprep
		 * profile of stringprep (e.g., in Nodeprep some characters can be
		 * mapped to nothing, which might result in a string of zero length).</p>
		 *
		 * @see http://tools.ietf.org/html/rfc6122#section-2.3
		 */
		public function get localpart():String
		{
