One document matched: draft-saintandre-username-interop-00.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-00">
<?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 have defined constructs for usernames. 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 have defined constructs for usernames. 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="Subset" anchor="subset">
<t>The following definition, in Augmented Backus-Naur Form (ABNF) <xref target='RFC5234'/>, describes an interoperable subset of characters for localparts / usernames:</t>
<figure>
<artwork><![CDATA[
localpart = 1*(interopchar)
interopchar = ALPHA / DIGIT / "!" / "$" / "*" / "+"
/ "-" / "=" / "_" / "`" / "|" / "~"
]]></artwork>
</figure>
<t>The reasoning behind this subset is provided in <xref target='analysis'/>.</t>
<t>An internationalized version would add the 'ucschar' rule from <xref target='RFC3987'/>. However, note that allowing characters outside the ASCII range <xref target='RFC20'/> can introduce numerous complexities; such issues are discussed in <xref target='I-D.ietf-precis-framework'/> among other specifications.</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>This document has no actions for the IANA.</t>
</section>
</middle>
<back>
<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='May' day='1' 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-04' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-appsawg-acct-uri-04.txt' />
</reference>
<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='September' day='23' year='2012' />
<abstract><t>Application protocols using Unicode code points in protocol strings need to prepare such strings in order to perform comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to handle various classes of strings in a way that depends on the properties of Unicode code points and that 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 base string classes or subclass the base string classes as needed. This framework takes an approach similar to the revised internationalized domain names 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 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-06' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-precis-framework-06.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='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='RFC3987'>
<front>
<title>Internationalized Resource Identifiers (IRIs)</title>
<author initials='M.' surname='Duerst' fullname='M. Duerst'>
<organization /></author>
<author initials='M.' surname='Suignard' fullname='M. Suignard'>
<organization /></author>
<date year='2005' month='January' />
<abstract>
<t>This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources.</t><t> The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs.</t></abstract></front>
<seriesInfo name='RFC' value='3987' />
<format type='TXT' octets='111190' target='http://www.rfc-editor.org/rfc/rfc3987.txt' />
</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='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='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>
</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 Address 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 allows 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.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:39:18 |