One document matched: draft-saintandre-username-interop-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc iprnotified="no" ?>
<?rfc sortrefs="no"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<rfc category="info" ipr="trust200902" docName="draft-saintandre-username-interop-01">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front>
<title abbrev="Username Interoperability">Username Interoperability</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3282</phone>
<email>psaintan@cisco.com</email>
</address>
</author>
<date/>
<abstract>
<t>Various Internet protocols define constructs for usernames, i.e., the local part of an address such as "localpart@example.com". This document describes a subset of characters to allow in usernames for maximal interoperability across Internet protocols. The subset might prove useful in cases where a provider offers multiple services using the same underlying identifier.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>Various Internet protocols define constructs for usernames, i.e., the local part of an address such as "localpart@example.com". This document describes a subset of characters to allow in usernames for maximal interoperability across Internet protocols. The subset might prove useful in cases where a provider offers multiple services using the same underlying identifier.</t>
</section>
<section title="Terminology" anchor="terms">
<t>Many important terms used in this document are defined in <xref target='I-D.ietf-precis-framework'/>, <xref target='RFC6365'/>, and <xref target='UNICODE'/>.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target='RFC2119'/>.</t>
</section>
<section title="Subset" anchor="subset">
<t>To define an interoperable subset of characters for local parts of application identifiers, this document subclasses the PRECIS IdentifierClass specified in <xref target='I-D.ietf-precis-framework'/>. In essence, the IdentifierClass restricts the allowable characters to lettersand digits from all the scripts of Unicode <xref target='UNICODE'/> while grandfathering in all the characters from the ASCII range <xref target='RFC20'/>. The subclass defined here, "UsernameIdentifierClass", further restricts the characters from the ASCII range to those known to work across multiple application protocols (as described under <xref target='analysis'/>).</t>
<t>The syntax is defined as follows using the Augmented Backus-Naur Form (ABNF) as specified in <xref target="RFC5234"/>.</t>
<figure>
<artwork><![CDATA[
uname = 1*1023(upoint)
;
; a "upoint" is a UTF-8 encoded Unicode code point
; that conforms to the "UsernameIdentifierClass"
; subclass of the PRECIS IdentifierClass
;
]]></artwork>
</figure>
<t>A uname MUST NOT be zero octets in length and MUST NOT be more than 1023 octets in length. This rule is to be enforced after any normalization and mapping of code points.</t>
<t>A uname MUST consist only of Unicode code points that conform to the "UsernameIdentifierClass" subclass of the "IdentifierClass" base string class defined in <xref target='I-D.ietf-precis-framework'/>. The UsernameIdentifierClass subclass includes all code points allowed by the IdentifierClass base class, with the exception of the following characters, which are disallowed:</t>
<t>
<list style='hanging'>
<t>U+0022 (QUOTATION MARK), i.e., '"'</t>
<t>U+0023 (NUMBER SIGN), i.e., '#'</t>
<t>U+0025 (PERCENT SIGN), i.e., '%'</t>
<t>U+0026 (AMPERSAND), i.e., '&'</t>
<t>U+0027 (APOSTROPHE), i.e., "'"</t>
<t>U+0028 (LEFT PARENTHESIS), i.e., '('</t>
<t>U+0029 (RIGHT PARENTHESIS), i.e., ')'</t>
<t>U+002C (COMMA), i.e., ','</t>
<t>U+002E (FULL STOP), i.e., '.'</t>
<t>U+002F (SOLIDUS), i.e., '/'</t>
<t>U+003A (COLON), i.e., ':'</t>
<t>U+003B (SEMICOLON), i.e., ';'</t>
<t>U+003C (LESS-THAN SIGN), i.e., '<'</t>
<t>U+003E (GREATER-THAN SIGN), i.e., '>'</t>
<t>U+003F (QUESTION MARK), i.e., '?'</t>
<t>U+0040 (COMMERCIAL AT), i.e., '@'</t>
<t>U+005B (LEFT SQUARE BRACKET), i.e., '['</t>
<t>U+005C (REVERSE SOLIDUS), i.e., '\'</t>
<t>U+005D (RIGHT SQUARE BRACKET), i.e., ']'</t>
<t>U+005E (CIRCUMFLEX ACCENT), i.e., '^'</t>
<t>U+0060 (GRAVE ACCENT), i.e., '`'</t>
<t>U+007B (LEFT CURLY BRACKET), i.e., '{'</t>
<t>U+007C (VERTICAL), i.e., '|'</t>
<t>U+007D (RIGHT CURLY BRACKET), i.e., '}'</t>
</list>
</t>
<t>The normalization and mapping rules for the UsernameIdentifierClass are as follows, where the operations specified MUST be completed in the order shown:</t>
<t>
<list style='numbers'>
<t>Fullwidth and halfwidth characters MUST be mapped to their decomposition equivalents.<vspace blankLines='1'/></t>
<t>So-called additional mappings MAY be applied, such as those defined in <xref target='I-D.ietf-precis-mappings'/>.<vspace blankLines='1'/></t>
<t>Uppercase and titlecase characters MUST be mapped to their lowercase equivalents.<vspace blankLines='1'/></t>
<t>All characters MUST be mapped using Unicode Normalization Form C (NFC).<vspace blankLines='1'/></t>
</list>
</t>
<t>With regard to directionality, applications MUST apply the "Bidi Rule" defined in <xref target='RFC5893'/> (i.e., each of the six conditions of the Bidi Rule must be satisfied).</t>
</section>
<section title="Security Considerations" anchor="security">
<t>Deploying usernames that are interoperable across multiple protocols could potentially give malicious entities multiple ways to attack an account or user.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>The IANA shall add the following entry to the PRECIS Subclass Registry:</t>
<t>
<list style='hanging'>
<t hangText='Subclass:'>UsernameIdentifierClass.</t>
<t hangText='Base Class:'>IdentifierClass.</t>
<t hangText='Exclusions:'>24 non-alphanumeric characters in the ASCII range.</t>
<t hangText='Specification:'>RFC XXXX. [Note to RFC Editor: please change XXXX to the number issued for this specification.]</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='I-D.ietf-precis-framework'>
<front>
<title>Precis Framework: Handling Internationalized Strings in Protocols</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization>Cisco</organization>
</author>
<author initials='M' surname='Blanchet' fullname='Marc Blanchet'>
<organization>Viagenie</organization>
</author>
<date month='July' day='10' year='2013' />
<abstract><t>Application protocols using Unicode code points in protocol strings need to properly prepare such strings in order to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation and comparison of internationalized strings (a.k.a. "PRECIS") in a way that depends on the properties of Unicode code points and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). A specification that reuses this framework can either directly use the PRECIS string classes or subclass the PRECIS string classes as needed. This framework takes an approach similar to the revised internationalized domain names (IDNs) in applications (IDNA) technology (RFC 5890, RFC 5891, RFC 5892, RFC 5893, RFC 5894) and thus adheres to the high-level design goals described in the IAB's recommendations regarding IDNs (RFC 4690), albeit for application technologies other than the Domain Name System (DNS). This document obsoletes RFC 3454.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-precis-framework-09' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-precis-framework-09.txt' />
</reference>
<reference anchor='I-D.ietf-precis-mappings'>
<front>
<title>Mapping characters for precis classes</title>
<author initials='Y' surname='Yoneya' fullname='Yoshiro Yoneya'>
<organization />
</author>
<author initials='T' surname='NEMOTO' fullname='Takahiro NEMOTO'>
<organization />
</author>
<date month='May' day='24' year='2013' />
<abstract><t>Preparation and comparison of internationalized strings ("precis") framework [I-D.ietf-precis-framework] is defining several classes of strings for preparation and comparison. In the document, case mapping is defined because many of protocols handle case sensitive or case insensitive string comparison and therefore preparation of string is mandatory. As described in IDNA mapping [RFC5895] and precis problem statement [I-D.ietf-precis-problem-statement], mappings in internationalized strings are not limited to case, but also width, delimiters and/or other specials are taken into consideration. This document is a guideline for authors of protocol profiles of precis framework and describes the mappings, that may be performed before precis framework, that must be considered between receiving user input and passing permitted code points to internationalized protocols.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-precis-mappings-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-precis-mappings-02.txt' />
</reference>
<reference anchor='RFC20'>
<front>
<title>ASCII format for network interchange</title>
<author initials='V.' surname='Cerf' fullname='Vint Cerf'>
<organization>University California Los Angeles (UCLA)</organization></author>
<date year='1969' day='16' month='October' />
<abstract>
<t>For concreteness, we suggest the use of standard 7-bit ASCII embedded in an 8 bit byte whose high order bit is always 0.</t></abstract></front>
<seriesInfo name='RFC' value='20' />
<format type='TXT' octets='18504' target='http://www.rfc-editor.org/rfc/rfc20.txt' />
</reference>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<reference anchor='RFC5234'>
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials='D.' surname='Crocker' fullname='D. Crocker'>
<organization /></author>
<author initials='P.' surname='Overell' fullname='P. Overell'>
<organization /></author>
<date year='2008' month='January' />
<abstract>
<t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='STD' value='68' />
<seriesInfo name='RFC' value='5234' />
<format type='TXT' octets='26359' target='http://www.rfc-editor.org/rfc/rfc5234.txt' />
</reference>
<reference anchor='RFC5893'>
<front>
<title>Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)</title>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
<organization /></author>
<author initials='C.' surname='Karp' fullname='C. Karp'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges. This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5893' />
<format type='TXT' octets='38870' target='http://www.rfc-editor.org/rfc/rfc5893.txt' />
</reference>
<reference anchor="UNICODE">
<front>
<title>The Unicode Standard, Version 3.2.0</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date year="2000" />
</front>
<annotation>
The Unicode Standard, Version 3.2.0 is defined by The Unicode Standard,
Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended
by the Unicode Standard Annex #27: Unicode 3.1
(http://www.unicode.org/reports/tr27/) and by the Unicode Standard Annex #28:
Unicode 3.2 (http://www.unicode.org/reports/tr28/).
</annotation>
</reference>
</references>
<references title="Informative References">
<reference anchor='I-D.ietf-appsawg-acct-uri'>
<front>
<title>The 'acct' URI Scheme</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization />
</author>
<date month='July' day='2' year='2013' />
<abstract><t>This document defines the 'acct' URI scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-appsawg-acct-uri-06' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-appsawg-acct-uri-06.txt' />
</reference>
<reference anchor='RFC821'>
<front>
<title>Simple Mail Transfer Protocol</title>
<author initials='J.B.' surname='Postel' fullname='Jonathan B. Postel'>
<organization>University of Southern California (USC)/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country></postal>
<phone>+1 213 822 1511</phone></address></author>
<date year='1982' day='1' month='August' /></front>
<seriesInfo name='STD' value='10' />
<seriesInfo name='RFC' value='821' />
<format type='TXT' octets='124482' target='http://www.rfc-editor.org/rfc/rfc821.txt' />
</reference>
<reference anchor='RFC2822'>
<front>
<title>Internet Message Format</title>
<author initials='P.' surname='Resnick' fullname='P. Resnick'>
<organization /></author>
<date year='2001' month='April' />
<abstract>
<t>This document specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='2822' />
<format type='TXT' octets='110695' target='http://www.rfc-editor.org/rfc/rfc2822.txt' />
</reference>
<reference anchor='RFC3261'>
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
<organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
<organization /></author>
<author initials='G.' surname='Camarillo' fullname='G. Camarillo'>
<organization /></author>
<author initials='A.' surname='Johnston' fullname='A. Johnston'>
<organization /></author>
<author initials='J.' surname='Peterson' fullname='J. Peterson'>
<organization /></author>
<author initials='R.' surname='Sparks' fullname='R. Sparks'>
<organization /></author>
<author initials='M.' surname='Handley' fullname='M. Handley'>
<organization /></author>
<author initials='E.' surname='Schooler' fullname='E. Schooler'>
<organization /></author>
<date year='2002' month='June' />
<abstract>
<t>This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='3261' />
<format type='TXT' octets='647976' target='http://www.rfc-editor.org/rfc/rfc3261.txt' />
</reference>
<reference anchor='RFC3856'>
<front>
<title>A Presence Event Package for the Session Initiation Protocol (SIP)</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
<organization /></author>
<date year='2004' month='August' />
<abstract>
<t>This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence Profile (CPP) framework. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='3856' />
<format type='TXT' octets='62956' target='http://www.rfc-editor.org/rfc/rfc3856.txt' />
</reference>
<reference anchor='RFC3860'>
<front>
<title>Common Profile for Instant Messaging (CPIM)</title>
<author initials='J.' surname='Peterson' fullname='J. Peterson'>
<organization /></author>
<date year='2004' month='August' />
<abstract>
<t>At the time this document was written, numerous instant messaging protocols were in use, and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='3860' />
<format type='TXT' octets='26486' target='http://www.rfc-editor.org/rfc/rfc3860.txt' />
</reference>
<reference anchor='RFC3986'>
<front>
<title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>Massachusetts Institute of Technology</street>
<street>77 Massachusetts Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>USA</country></postal>
<phone>+1-617-253-5702</phone>
<facsimile>+1-617-258-5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3.org/People/Berners-Lee/</uri></address></author>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='Day Software'>Day Software</organization>
<address>
<postal>
<street>5251 California Ave., Suite 110</street>
<city>Irvine</city>
<region>CA</region>
<code>92617</code>
<country>USA</country></postal>
<phone>+1-949-679-2960</phone>
<facsimile>+1-949-679-2972</facsimile>
<email>fielding@gbiv.com</email>
<uri>http://roy.gbiv.com/</uri></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Adobe Systems'>Adobe Systems Incorporated</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country></postal>
<phone>+1-408-536-3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net/</uri></address></author>
<date year='2005' month='January' />
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>URN</keyword>
<keyword>WWW</keyword>
<keyword>resource</keyword>
<abstract>
<t>
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource. This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier. This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
</t></abstract></front>
<seriesInfo name='STD' value='66' />
<seriesInfo name='RFC' value='3986' />
<format type='TXT' octets='141811' target='http://www.rfc-editor.org/rfc/rfc3986.txt' />
<format type='HTML' octets='213584' target='http://xml.resource.org/public/rfc/html/rfc3986.html' />
<format type='XML' octets='163534' target='http://xml.resource.org/public/rfc/xml/rfc3986.xml' />
</reference>
<reference anchor='RFC4120'>
<front>
<title>The Kerberos Network Authentication Service (V5)</title>
<author initials='C.' surname='Neuman' fullname='C. Neuman'>
<organization /></author>
<author initials='T.' surname='Yu' fullname='T. Yu'>
<organization /></author>
<author initials='S.' surname='Hartman' fullname='S. Hartman'>
<organization /></author>
<author initials='K.' surname='Raeburn' fullname='K. Raeburn'>
<organization /></author>
<date year='2005' month='July' />
<abstract>
<t>This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC 1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4120' />
<format type='TXT' octets='340314' target='http://www.rfc-editor.org/rfc/rfc4120.txt' />
</reference>
<reference anchor='RFC4282'>
<front>
<title>The Network Access Identifier</title>
<author initials='B.' surname='Aboba' fullname='B. Aboba'>
<organization /></author>
<author initials='M.' surname='Beadles' fullname='M. Beadles'>
<organization /></author>
<author initials='J.' surname='Arkko' fullname='J. Arkko'>
<organization /></author>
<author initials='P.' surname='Eronen' fullname='P. Eronen'>
<organization /></author>
<date year='2005' month='December' />
<abstract>
<t>In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, \%customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and \%ISP-provided corporate network access support. This document is a revised version of RFC 2486, which originally defined NAIs. Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4282' />
<format type='TXT' octets='34421' target='http://www.rfc-editor.org/rfc/rfc4282.txt' />
</reference>
<reference anchor='RFC5322'>
<front>
<title>Internet Message Format</title>
<author initials='P.' surname='Resnick' fullname='Peter W.
Resnick' role='editor'>
<organization>Qualcomm Incorporated</organization>
<address>
<postal>
<street>5775 Morehouse Drive</street>
<city>San Diego</city>
<region>CA</region>
<code>92121-1714</code>
<country>US</country></postal>
<phone>+1 858 651 4478</phone>
<email>presnick@qualcomm.com</email>
<uri>http://www.qualcomm.com/~presnick/</uri></address></author>
<date year='2008' month='October' />
<abstract>
<t>This document specifies the Internet
Message Format (IMF), a syntax for text messages
that are sent between computer users, within
the framework of "electronic mail"
messages. This specification is a revision of
Request For Comments (RFC) 2822, which
itself superseded Request For Comments (RFC)
822, "Standard for the Format of ARPA
Internet Text Messages", updating it to
reflect current practice and incorporating
incremental changes that were specified in
other RFCs.</t></abstract></front>
<seriesInfo name='RFC' value='5322' />
<format type='TXT' octets='122322' target='http://www.rfc-editor.org/rfc/rfc5322.txt' />
<format type='HTML' octets='213393' target='http://xml.resource.org/public/rfc/html/rfc5322.html' />
<format type='XML' octets='174234' target='http://xml.resource.org/public/rfc/xml/rfc5322.xml' />
</reference>
<reference anchor='RFC6120'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<t>The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6120' />
<format type='TXT' octets='451942' target='http://www.rfc-editor.org/rfc/rfc6120.txt' />
</reference>
<reference anchor='RFC6365'>
<front>
<title>Terminology Used in Internationalization in the IETF</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2011' month='September' />
<abstract>
<t>This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo documents an Internet Best Current Practice.</t></abstract></front>
<seriesInfo name='BCP' value='166' />
<seriesInfo name='RFC' value='6365' />
<format type='TXT' octets='103155' target='http://www.rfc-editor.org/rfc/rfc6365.txt' />
</reference>
</references>
<section title="Analysis" anchor="analysis">
<t>This document takes the following username constructs into consideration:</t>
<t>
<list style='symbols'>
<t>Email addresses <xref target='RFC5322'/></t>
<t>Kerberos Principal Names <xref target='RFC4120'/></t>
<t>Network Access Identifiers <xref target='RFC4282'/></t>
<t>SIP URIs <xref target='RFC3261'/></t>
<t>Instant messaging URIs <xref target='RFC3860'/> and presence URIs <xref target='RFC3856'/></t>
<t>XMPP addresses (a.k.a. Jabber Identifiers) <xref target='RFC6120'/></t>
<t>Account URIs <xref target='I-D.ietf-appsawg-acct-uri'/></t>
</list>
</t>
<t>Each of those address formats defines something that can be used as the "local part" of an address.</t>
<t>The local part of an email address uses either the "local-part" or the "dot-atom-text" rule in <xref target='RFC5322'/>. Here we make the simplifying assumption that the "dot-atom-text" rule applies:</t>
<figure>
<artwork><![CDATA[
dot-atom-text = 1*atext *("." 1*atext)
atext = ALPHA / DIGIT / ; Any character except
"!" / "#" / "$" / ; controls, SP, and
"%" / "&" / "'" / ; specials. Used for
"*" / "+" / "-" / ; atoms.
"/" / "=" / "?" /
"^" / "_" / "`" /
"{" / "|" / "}" /
"~"
]]></artwork>
</figure>
<t>We make the same simplifying assumption for im: and pres: URIs (although their specifications reference <xref target='RFC2822'/>).</t>
<t>A Kerberos Principal Name is a sequence of strings of type KerberosString, where each KerberosString is a GeneralString that is constrained to contain only characters in IA5String.</t>
<figure>
<artwork><![CDATA[
PrincipalName ::= SEQUENCE {
name-type [0] Int32,
name-string [1] SEQUENCE OF KerberosString
}
KerberosString ::= GeneralString (IA5String)
]]></artwork>
</figure>
<t>A Network Address Identifier inherits from <xref target='RFC821'/>. Here we care only about the "username" rule:</t>
<figure>
<artwork><![CDATA[
username = dot-string
dot-string = string
dot-string =/ dot-string "." string
string = char
string =/ string char
char = c
char =/ "\" x
c = %x21 ; '!' allowed
; '"' not allowed
c =/ %x23 ; '#' allowed
c =/ %x24 ; '$' allowed
c =/ %x25 ; '%' allowed
c =/ %x26 ; '&' allowed
c =/ %x27 ; ''' allowed
; '(', ')' not allowed
c =/ %x2A ; '*' allowed
c =/ %x2B ; '+' allowed
; ',' not allowed
c =/ %x2D ; '-' allowed
; '.' not allowed
c =/ %x2F ; '/' allowed
c =/ %x30-39 ; '0'-'9' allowed
; ';', ':', '<' not allowed
c =/ %x3D ; '=' allowed
; '>' not allowed
c =/ %x3F ; '?' allowed
; '@' not allowed
c =/ %x41-5a ; 'A'-'Z' allowed
; '[', '\', ']' not allowed
c =/ %x5E ; '^' allowed
c =/ %x5F ; '_' allowed
c =/ %x60 ; '`' allowed
c =/ %x61-7A ; 'a'-'z' allowed
c =/ %x7B ; '{' allowed
c =/ %x7C ; '|' allowed
c =/ %x7D ; '}' allowed
c =/ %x7E ; '~' allowed
; DEL not allowed
c =/ %x80-FF ; UTF-8-Octet allowed
x = %x00-FF ; all 128 ASCII characters
]]></artwork>
</figure>
<t>The local part of a sip:/sips: URI inherits from the "userinfo" rule in <xref target="RFC3986"/> with several changes; here we discuss the SIP "user" rule only:</t>
<figure>
<artwork><![CDATA[
user = 1*( unreserved / escaped / user-unreserved )
user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" / "'"
/ "(" / ")"
]]></artwork>
</figure>
<t>The local part of an XMPP address allows any ASCII character except space, controls, and the " & ' / : < > @ characters.</t>
<t>The 'acct' URI syntax borrows the 'host', 'pct-encoded', 'sub-delims', 'unreserved' rules from <xref target='RFC3986'/>:</t>
<figure>
<artwork><![CDATA[
acctURI = "acct" ":" userpart "@" host
userpart = unreserved / sub-delims
0*( unreserved / pct-encoded / sub-delims )
]]></artwork>
</figure>
<t>To summarize the foregoing information, the following table lists the allowed and disallowed characters in the local part of identifiers for each protocol (aside from the alphanumeric, space, and control characters), in order by hexadecimal character number (where each "A" row shows the allowed characters and each "D" row shows the disallowed characters).</t>
<figure>
<preamble>Table 1: Allowed and Disallowed Characters (Non-Alphanumeric)</preamble>
<artwork><![CDATA[
+---+----------------------------------+
| EMAIL ADDRESSES, IM/PRES URIs |
+---+----------------------------------+
| A | ! #$%&' *+ - / = ? ^_`{|}~ |
| D | " () , . :;< > @[\] |
+---+----------------------------------+
| KERBEROS PRINCIPAL NAMES |
+---+----------------------------------+
| A | !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~ |
| D | |
+---+----------------------------------+
| NETWORK ADDRESS IDENTIFIERS |
+---+----------------------------------+
| A | ! #$%&' *+ - / = ? ^_`{|}~ |
| D | " () , . :;< > @[\] |
+---+----------------------------------+
| SIP/SIPS URIs |
+---+----------------------------------+
| A | ! $ &'()*+,-./ ; = ? _ ~ |
| D | "# % : < > @[\]^ `{|} |
+---+----------------------------------+
| XMPP ADDRESSES |
+---+----------------------------------+
| A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ |
| D | " &' /: < > @ |
+---+----------------------------------+
| ACCT URIs |
+---+----------------------------------+
| A | ! $%&'()*+,-. ; = \ ^_`{|}~ |
| D | "# /: < >?@[ ] |
+---+----------------------------------+
]]></artwork>
</figure>
<t>The interoperable subset allows only characters that are allowed in all of the foregoing formats, as shown in the following table.</t>
<figure>
<preamble>Table 2: Subset Characters (Non-Alphanumeric)</preamble>
<artwork><![CDATA[
+---+----------------------------------+
| INTEROPERABLE SUBSET |
+---+----------------------------------+
| A | ! $ *+ - = _ ~ |
| D | "# %&'() , ./:;< >?@[\]^ `{|} |
+---+----------------------------------+
]]></artwork>
</figure>
</section>
<section title="Acknowledgements" anchor="acks">
<t>Thanks to Sean Turner for inspiring the work on this document. Thanks also to Paul Hoffman, John Klensin, and Glen Zorn for their comments.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:37:53 |