]> Internationalized Email Addresses in JSContact IIT-CNR/Registro.it
Via Moruzzi, 1 Pisa 56124 Italy mario.loffredo@iit.cnr.it https://www.iit.cnr.it
Fastmail
PO Box 234 Collins St. West Melbourne VIC 8007 Australia rsto@fastmailteam.com https://www.fastmail.com
Applications and Real-Time Calendaring Extensions JSContact EAI JSContact defines the EmailAddress object for representing an email address, but its address property is restricted to the ASCII syntax of an addr-spec in RFC 5322. This document redefines that property to also support internationalized email addresses, as defined in RFC 6532. Since such values are incompatible with JSContact version 2.0, this document defines JSContact version 3.0. This document updates RFC 9553.
Introduction defines the EmailAddress address property as an addr-spec value conforming to . That syntax does not allow non-ASCII characters in a mailbox local-part. However, Email Address Internationalization (EAI) extends Internet mail to allow UTF-8 characters in email addresses. In particular, defines the relevant extensions to the syntax specified in . This document extends the syntax of the EmailAddress address property to also allow internationalized email addresses and defines JSContact version 3.0, which succeeds version 2.0 .
Conventions and Terminology 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 BCP 14 when, and only when, they appear in all capitals, as shown here. In this document, an addr-spec that contains at least one non-ASCII character is called an internationalized email address.
JSContact Version 3.0 This document defines JSContact version "3.0". The values newly permitted for the address property by can be rejected by an implementation of JSContact version 2.0 , so this change is backwards incompatible according to and requires a new major version. Implementations that create a Card containing an internationalized email address as defined in MUST set the Card version property to "3.0" or a later version that permits such an address. In contrast, every Card that is valid according to JSContact version 2.0 is also valid according to version 3.0. Existing data therefore does not need to be migrated merely because version 3.0 has been defined. Except for the change defined in this document, all JSContact version 2.0 definitions remain unchanged.
Redefined EmailAddress address Property This section replaces the definition of the address property in . Its type signature and mandatory status do not change. OLD:
address: String (mandatory). The email address. This MUST be an addr-spec value as defined in .
NEW:
address: String (mandatory). The email address. This MUST be an addr-spec value as defined in , extended to support UTF-8 as specified in .
This document does not define normalization or comparison rules for email addresses. The syntax and interpretation of internationalized email addresses, including the representation of non-ASCII domain names, are as specified in and the documents it references.
Example
Card Containing an Internationalized Email Address
Implementation and Interoperability Considerations How to interoperate with systems that do not support version 3.0 or later is specific to the protocol used to exchange JSContact data and is out of scope for this document. Converting internationalized email addresses from and to vCard is out of scope for this document; it is addressed in .
IANA Considerations
Update to the JSContact Version Registry IANA is requested to add the following entry to the "JSContact Version" registry in the "JSContact" registry group: JSContact Version Registry
Major VersionHighest Minor VersionReference
30This document
Update to the JSContact Properties Registry IANA is requested to add a reference to of this document to the "Reference or Description" field of the address property in the EmailAddress context in the "JSContact Properties" registry.
Security Considerations The security considerations of apply. In addition, the security considerations for email addresses in and apply. Allowing non-ASCII characters in email addresses increases the risk that visually similar characters will be mistaken for one another. This can be used to create an address that appears to a user to be another address. User interfaces SHOULD make potentially deceptive characters or labels apparent and SHOULD provide a way to inspect the exact address. Implementations MUST preserve the complete address and MUST NOT use display similarity as evidence that two addresses identify the same mailbox.
References Normative References Informative References