Username InteroperabilityCisco Systems, Inc.1899 Wynkoop Street, Suite 600DenverCO80202USA+1-303-308-3282psaintan@cisco.comVarious 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.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.Many important terms used in this document are defined in , , and .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 .To define an interoperable subset of characters for local parts of application identifiers, this document specifies a profile of the PRECIS IdentifierClass specified in . In essence, the IdentifierClass restricts the allowable characters to letters and digits from all the scripts of Unicode while grandfathering in all the characters from the ASCII range . The profile defined here, "UsernameIdentifierClass", further restricts the characters from the ASCII range to those known to work across multiple application protocols (as described under ).The syntax is defined as follows using the Augmented Backus-Naur Form (ABNF) as specified in .A uname MUST consist only of Unicode code points that conform to the "UsernameIdentifierClass" profile of the "IdentifierClass" base string class defined in . The UsernameIdentifierClass profile includes all code points allowed by the IdentifierClass base class, with the exception of the following characters, which are disallowed:U+0022 (QUOTATION MARK), i.e., '"'U+0023 (NUMBER SIGN), i.e., '#'U+0025 (PERCENT SIGN), i.e., '%'U+0026 (AMPERSAND), i.e., '&'U+0027 (APOSTROPHE), i.e., "'"U+0028 (LEFT PARENTHESIS), i.e., '('U+0029 (RIGHT PARENTHESIS), i.e., ')'U+002C (COMMA), i.e., ','U+002E (FULL STOP), i.e., '.'U+002F (SOLIDUS), i.e., '/'U+003A (COLON), i.e., ':'U+003B (SEMICOLON), i.e., ';'U+003C (LESS-THAN SIGN), i.e., '<'U+003E (GREATER-THAN SIGN), i.e., '>'U+003F (QUESTION MARK), i.e., '?'U+0040 (COMMERCIAL AT), i.e., '@'U+005B (LEFT SQUARE BRACKET), i.e., '['U+005C (REVERSE SOLIDUS), i.e., '\'U+005D (RIGHT SQUARE BRACKET), i.e., ']'U+005E (CIRCUMFLEX ACCENT), i.e., '^'U+0060 (GRAVE ACCENT), i.e., '`'U+007B (LEFT CURLY BRACKET), i.e., '{'U+007C (VERTICAL), i.e., '|'U+007D (RIGHT CURLY BRACKET), i.e., '}'The normalization and mapping rules for the UsernameIdentifierClass are as follows, where the operations specified MUST be completed in the order shown:Fullwidth and halfwidth characters MUST be mapped to their decomposition equivalents.So-called additional mappings MAY be applied, such as those defined in .Uppercase and titlecase characters MUST be mapped to their lowercase equivalents.All characters MUST be mapped using Unicode Normalization Form C (NFC).With regard to directionality, applications MUST apply the "Bidi Rule" defined in (i.e., each of the six conditions of the Bidi Rule must be satisfied).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.Deploying usernames that are interoperable across multiple protocols could potentially give malicious entities multiple ways to attack an account or user.The IANA shall add the following entry to the PRECIS Profiles Registry:UsernameIdentifierClass.Usernames that are intended to be interoperable across multiple application protocols.IdentifierClass.None.Map fullwidth and halfwidth characters to their decomposition equivalents.None required or recommended.Map uppercase and titlecase characters to lowercase.NFC.The "Bidi Rule" defined in RFC 5893 applies.24 non-alphanumeric characters in the ASCII range.Up to the application protocol or deployment.RFC XXXX. [Note to RFC Editor: please change XXXX to the number issued for this specification.]Precis Framework: Handling Internationalized Strings in ProtocolsCiscoViagenieApplication 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). This document obsoletes RFC 3454.Mapping characters for precis classesPreparation 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.ASCII format for network interchangeUniversity California Los Angeles (UCLA)For concreteness, we suggest the use of standard 7-bit ASCII embedded in an 8 bit byte whose high order bit is always 0.Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
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:
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.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
Augmented BNF for Syntax Specifications: ABNFInternet 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]Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)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]The Unicode Standard, Version 3.2.0The Unicode Consortium
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/).
The 'acct' URI SchemeThis 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.Simple Mail Transfer ProtocolUniversity of Southern California (USC)/Information Sciences Institute4676 Admiralty WayMarina del ReyCA90291US+1 213 822 1511Internet Message FormatThis document specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. [STANDARDS-TRACK]SIP: Session Initiation ProtocolThis 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]A Presence Event Package for the Session Initiation Protocol (SIP)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]Common Profile for Instant Messaging (CPIM)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]Uniform Resource Identifier (URI): Generic SyntaxWorld Wide Web ConsortiumMassachusetts Institute of Technology77 Massachusetts AvenueCambridgeMA02139USA+1-617-253-5702+1-617-258-5999timbl@w3.orghttp://www.w3.org/People/Berners-Lee/Day Software5251 California Ave., Suite 110IrvineCA92617USA+1-949-679-2960+1-949-679-2972fielding@gbiv.comhttp://roy.gbiv.com/Adobe Systems Incorporated345 Park AveSan JoseCA95110USA+1-408-536-3024LMM@acm.orghttp://larry.masinter.net/
Applications
uniform resource identifierURIURLURNWWWresource
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.
The Kerberos Network Authentication Service (V5)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]The Network Access IdentifierIn 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]Internet Message FormatQualcomm Incorporated5775 Morehouse DriveSan DiegoCA92121-1714US+1 858 651 4478presnick@qualcomm.comhttp://www.qualcomm.com/~presnick/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.Extensible Messaging and Presence Protocol (XMPP): CoreThe 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]Terminology Used in Internationalization in the IETFThis 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.This document takes the following username constructs into consideration:Email addresses Kerberos Principal Names Network Access Identifiers SIP URIs Instant messaging URIs and presence URIs XMPP addresses (a.k.a. Jabber Identifiers) Account URIs Each of those address formats defines something that can be used as the "local part" of an address.The local part of an email address uses either the "local-part" or the "dot-atom-text" rule in . Here we make the simplifying assumption that the "dot-atom-text" rule applies:We make the same simplifying assumption for im: and pres: URIs (although their specifications reference ).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.A Network Address Identifier inherits from . Here we care only about the "username" rule:The local part of a sip:/sips: URI inherits from the "userinfo" rule in with several changes; here we discuss the SIP "user" rule only:The local part of an XMPP address allows any ASCII character except space, controls, and the " & ' / : < > @ characters.The 'acct' URI syntax borrows the 'host', 'pct-encoded', 'sub-delims', 'unreserved' rules from :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).The interoperable subset allows only characters that are allowed in all of the foregoing formats, as shown in the following table.Thanks to Sean Turner for inspiring the work on this document. Thanks also to Paul Hoffman, John Klensin, and Glen Zorn for their comments.