IMAP Goes Global; It’s Just My Deprecation; No Time Like The Present

It’s been a minute since we’ve checked in with RFC-land, so I’ve plucked a few of the more interesting and impactful (for us) ones to talk about today.

TL;DR

(This is an AI-generated summary of today’s Drop using Ollama + llama 3.2 and a custom prompt.)

• RFC 9755 extends IMAP4rev1 to support UTF-8 encoded international characters in usernames, addresses, and headers, allowing proper display of non-Latin names and writing systems through UTF8=ACCEPT and UTF8=ONLY capabilities (https://www.rfc-editor.org/info/rfc9755)
• RFC 9745 introduces the standardized Deprecation HTTP header to communicate API endpoint lifecycle information directly in responses, enabling runtime discovery and programmatic detection of deprecated endpoints (https://www.rfc-editor.org/info/rfc9745)
• RFC 9748 updates several NTP and NTS registries maintained by IANA, correcting assignments and implementing more rigorous registration procedures to improve the security of time synchronization protocols (https://www.rfc-editor.org/info/rfc9748)

IMAP Goes Global

RFC 9755 (IMAP Support for UTF-8) extends the IMAP4rev1 protocol to be fully support UTF-8 encoded international characters across email systems. This standard addresses a long-standing limitation that has restricted folks with non-Latin names and writing systems.

Despite the internet’s global reach, email protocols have historically been constrained by ASCII-only limitations. This creates real barriers for billions of folks who communicate in non-Latin writing systems. Traditional email standards required all header values to conform to ASCII characters, forcing individuals with non-Latin names to modify their identities for online communication.

These limitations originated from email’s development in an ASCII-centric computing environment. Previous solutions implemented complex encoding schemes such as MIME-encoded words to incorporate non-ASCII characters in certain header fields, but these approaches were inadequate and inconsistently implemented.

The specification introduces two key capabilities:

UTF8=ACCEPT: This capability enables servers to support internationalized messages, UTF-8 responses, and UTF-8 in quoted-strings.

UTF8=ONLY: This designation applies to servers that mandate UTF-8 support from clients and no longer accept the modified UTF-7 international mailbox name convention.

With these new capabilities, we will have the ability to open mailboxes containing fully internationalized messaged. We also get native UTF-8 in quoted strings, which have usually involved icky workarounds. Mailbox names can also now be fully internationalized, and email addresses can include glyphs from all writing systems.

RFC 9755 supersedes RFC 6855 and addresses implementation challenges that hindered previous internationalization attempts. Earlier approaches, such as RFC 5738 from way back in 2010, established experimental frameworks for this functionality, but implementation complexity limited widespread adoption.

The timing of RFC 9755 coincides with global internet demographics where non-English speakers constitute the majority, creating sufficient market pressure for standardized international character support.

What does this mean for those of us who just use email?

First off, we’ll see any international colleagues’ names displayed correctly without garbled characters or formatting issues. This will help make communications inclusive and culturally respectful by properly handling diverse languages and scripts. Additionally, we’ll experience more consistent text handling across different email systems, reducing frustrating formatting problems when exchanging messages with people using various email providers. These improvements collectively should help make the everyday email experience more seamless and globally connected.

Developers now have formal, standard requirements to implement UTF-8 support throughout the email pipeline. Existing codebase will need to be adapted for this new UTF-8 support, and legacy systems that can’t be modified will need transition plans.

It’ll take a while for this to be in the majority of IMAP and client app deployments, but it will be a welcome change.

It’s Just My Deprecation

API providers face a persistent challenge: effectively communicating when endpoints are being deprecated. Traditional methods — documentation updates, email notifications, custom headers, or response body warnings — often fail to reach developers in time, resulting in broken applications when endpoints are finally removed.

RFC 9745 introduces the Deprecation HTTP header, providing a standardized mechanism to communicate API lifecycle information directly in HTTP responses:

Deprecation: @1688169599

This header indicates the resource was deprecated on June 30, 2023. The timestamp can represent either past or future deprecation dates, allowing for proactive notification.

This new header offers several advantages:

1. Deprecation notices are delivered with each response
2. Automated tools can identify and flag deprecated endpoints
3. Standardization enables ecosystem-wide tooling
4. Deprecation information remains separate from response payloads
5. Future deprecation dates enable orderly transitions

The standard also introduces a “deprecation” link relation type that points to relevant documentation:

Link: <https://example.com/deprecation/v1/users>; rel="deprecation"; type="text/html"

This link can provide context about alternatives, migration guides, and support resources.

For resources with planned removal dates, the Deprecation header can be combined with a new Sunset header:

Deprecation: @1688169599
Sunset: Sun, 30 Jun 2024 23:59:59 UTC

While the Deprecation header provides a technical solution, you are not off the hook so easily. You still need to do comms to humans in all the places your API community live. And, you also need to still provide extensive documentation and be available to help answer trransition questions. These new headers just proide some extra awareness.

This new standard should help us all build and deploy more resilient applications and manage dependencies more effectively, which will hopefully lead to a more stable and predictable web ecosystem.

No Time Like The Present

RFC 9748 (Updating the NTP Registries) updates several previous RFCs (5905, 5906, 7821, 7822, and 8573) related to the Network Time Protocol (NTP) and Network Time Security (NTS).

Specifically, it addresses issues with existing NTP and NTS registries maintained by IANA. While some registries were correct, others contained incorrect assignments or didn’t follow common practices. RFC 9748 provides a comprehensive review of all NTP and NTS registries and makes necessary corrections.

The details are pretty wonk-ish, so we’ll leave you to hit up the RFC directly (if you, heh, have the time).

By establishing a more rigorous registration procedure (speficially, changing from “First Come First Served” to “Specification Required”) and implementing a designated expert system requiring approval from two of three experts, the registry changes should help ensure that future NTP extensions will be properly vetted. This improves the overall security posture of NTP, which is critical since accurate time synchronization is quite important for many security protocols like TLS, Bitcoin, Kerberos, RPKI, and DNSSEC.

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on:

• 🐘 Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev
• 🦋 Bluesky via https://bsky.app/profile/dailydrop.hrbrmstr.dev.web.brid.gy

Also, refer to:

• this post, and
• this post

to see how to access a regularly updated database of all the Drops with extracted links, and full-text search capability. ☮️