Технические условия готовности к универсальному принятию

Чтобы приложение или сайт считались поддерживающими универсальное принятие, они должны удовлетворять различным требованиям:

Требования высокого уровня

Обеспечивающее универсальное принятие (UA) приложение или сервис:

  1. Поддерживает все доменные имена независимо от длины или набора символов. См. RFC 5892;
  2. Позволяет использовать для доменных имен и адресов электронной почты все допустимые наборы символов. Принимает символы Unicode и ASCII;
  3. Может правильно отображать все символы в строках Unicode. См. RFC 3490. (Обратите внимание, что в Unicode регулярно добавляются новые наборы символов);
  4. Может правильно отображать строки с направлением письма справа налево (RTL), например, на арабском и иврите. Сведения об алфавитах RTL см. в RFC 5893;
  5. Может передавать данные между приложениями и сервисами в формате UTF-8 и, при необходимости, в других кодировках, которые могут быть преобразованы в UTF-8 и обратно. Сведения о UTF-8 см. в RFC 3629;
  6. Предлагает публичные и закрытые API, которые поддерживают UTF-8. Закрытые API применяются только при обмене данными между службами одного и того же поставщика;
  7. Правильно обрабатывает адреса EAI. В частности, не преобразует IDN-домены в адресах в A-метки.
  8. Может отправлять и получать электронную почту, независимо от имени домена или набора символов. См. RFC 6530;
  9. Хранит пользовательские данные в форматах, которые поддерживают Unicode и могут быть преобразованы в UTF-8 и обратно. Такие преобразования будут видны только оператору продукта или сервиса.
  10. Поддерживает все доменные имена верхнего уровня, включенные в официальный список TLD ICANN, независимо от их длины или набора символов. Официальный список см. здесь: data.iana.org/TLD/.

Важные для разработчика аспекты

Поскольку многие существующие программные системы содержат жестко запрограммированные предположения о доменах и адресах электронной почты, может возникнуть необходимость изменения кода для распознавания IDN-доменов, новых TLD и почтовых адресов EAI. В этом разделе рассматривается, какие изменения кода позволят разработчикам обеспечить универсальное принятие.

Разработка совместимого и гибкого программного обеспечения

Общим принципом разработки программного обеспечения является принцип надежности, сформулированный Джоном Постелом в RFC 793: «Будьте консервативны в том, что делаете, и будьте либеральны в том, что принимаете от других».

То есть будьте консервативны в том, что отправляете: в любой области, где спецификация может быть неоднозначной или неясной, избегайте всего, что может удивить других. С другой стороны, при получении принимайте все, что является предположительно допустимым. Это не означает изменение кода для обхода очевидных ошибок в других реализациях, так как результатом подобной практики станет недокументированный и «не поддающийся отладке» беспорядок.