Internet Engineering Task Force (IETF) U. Sharma Request for Comments: 9557 Igalia, S.L. Updates: 3339 C. Bormann Category: Standards Track Universität Bremen TZI ISSN: 2070-1721 April 2024
Date and Time on the Internet: Timestamps with Additional Information
Даты и время в Internet – временные метки с дополнительной информацией
Аннотация
В этом документе определено расширение формата временных меток, заданного в RFC 3339, для представления дополнительных сведений, включая часовой пояс.
Документ обновляет RFC 3339 в части интерпретации локального смещения Z, которое больше не считается «подразумевающим, что UTC является предпочтительной точкой отсчёта для указанного времени».
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9557.
Авторские права
Авторские права (Copyright (c) 2024) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Revised BSD License).
1. Ведение
Даты и время применяются в самых разных приложениях Internet – от ведения журналов на серверах до создания календарей и расписаний.
Каждый момент времени может быть представлен в описательном текстовом формате с использованием временной метки. В [ISO8601-1:2019] стандартизован широко применяемый формат временных меток, а ранняя версия стандарта [ISO8601:1988] стала основой для формата дат и времени в Internet [RFC3339]. Однако этот формат очень ограничивает включение в метки дополнительной информации. Кроме того, любые контекстные сведения, связанные с данной временной меткой, требуется обрабатывать отдельно или добавлять нестандартным способом.
Это важно для приложений, обрабатывающих временные метки с именем часового пояса для учёта таких событий, как переход на сезонное время. Многие из таких приложений добавляют часовой пояс во временную метку нестандартным способом и по меньшей мере один из таких форматов ([JAVAZDT]) получил широкое распространение. Кроме того, приложения могут добавлять к временной метке другие сведения, такие как указание календарной системы, в которой следует представлять метку, и т. п.
Этот документ задаёт расширение формата временных меток [RFC3339] для представления дополнительных сведений, включая часовой пояс.
Документ обновляет [RFC3339] в части интерпретации локального смещения Z, которое больше не считается «подразумевающим, что UTC является предпочтительной точкой отсчёта для указанного времени» (см. раздел 2).
1.1. Область действия
В [RFC3339] задан синтаксис временных меток для представления даты и времени в Internet. Настоящий документ задаёт синтаксис расширения с указанными ниже свойствами.
-
Суффикс расширения не обязателен, что делает метки [RFC3339] совместимыми с новым форматом.
-
Формат совместим с имеющимся популярным синтаксисом для добавления в метки времени имён часовых поясов [JAVAZDT].
-
Формат обеспечивает обобщенный способ добавления информации во временные метки.
Этот формат назван расширенным форматом дат и времени Internet (Internet Extended Date/Time Format или IXDTF).
В данном документе не рассматриваются расширения формата, в которых семантический результат больше не является временной меткой, указывающей (прошлое или будущее) время UTC. Например, не рассматриваются:
-
время в будущем, указанное как местное время в конкретном часовом поясе, когда изменения в определении этого часового пояса (такие, как политические решения о введении или отмене перехода на сезонное время) влияют на момент, представляемый временной меткой;
-
«плавающее время», т. е. местное время без указания смещения от UTC или часового пояса, в котором следует интерпретировать время;
-
использование временных шкал, отличающихся от UTC, например, международных атомных часов (International Atomic Time или TAI).
Однако дополнительных сведений в фиксированной временной метке может быть достаточно для обнаружения несоответствия между намерением и фактическими данными временной метки, такими как смещение от UTC или имя часового пояса. Несоответствия могут возникать, например, в результате:
-
политических решений, как отмечено выше;
-
обновления определения часовых поясов, применяемые в разное время создателями и получателями временных меток;
-
ошибок в программах, создающих и применяющих временные метки.
Хотя сведений из строки IXDTF в общем случае не достаточно для исправления несоответствий, они могут служить для инициирования отдельной (out-of-band) обработки с целью получения нужных для устранения несоответствия данных.
Для выполнения некоторых требований, подразумеваемых здесь, будущие спецификации могут задавать синтаксис и семантику строк, похожие на описанные в [RFC3339]. Отметим, что заданный здесь синтаксис расширения разработан так, что он может быть полезен и для таких спецификаций.
1.2. Определения
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
UTC
Всемирное координированное время (Coordinated Universal Time), поддерживаемое с 1988 г. Международным бюро мер и весов (Bureau International des Poids et Mesures или BIPM) с учётом високосных секунд, указываемых Международной службой вращения земли и эталонных систем (International Earth Rotation and Reference Systems Service) [IERS]. С 1972 г. до 1987 г поддержка UTC полностью обеспечивалась Международным бюро времени (Bureau International de l’Heure или BIH). До 1972 г. не было общего признания UTC и гражданское время определялось отдельными юрисдикциями, использующими разные методы, чтобы пытаться следовать Мировому времени (Universal Time) на основе измерений вращения Земли. UTC часто ошибочно называют GMT (Greenwich Mean Time – среднее время по Гринвичу) – более ранней шкалой времени, преемником которой является UTC.ABNF
Дополненная форма Бэкуса-Наура (Augmented Backus-Naur Form) – формат, применяемый для представления допустимых строка протокола или языка, как определено в [RFC5234]. Правила Приложения B к [RFC5234] импортируются неявно.IXDTF
Расширенный формат дат и времени Internet (Internet Extended Date/Time Format), заданный в разделе 4.Timestamp – временная метка
Однозначное представление определённого момента времени.UTC Offset – смещение от UTC
Разница между местным временем и UTC, обычно указываемая положительным или отрицательным числом часов и минут. Например, местное время в городе Нью-Йорк (New York, NY, USA) зимой 2023 г. отставало на 5 часов от UTC, поэтому смещение UTC было -05:00.Z
Суффикс, который применительно ко времени означает смещение от UTC 00:00. Обычно произносится как Zulu по фонетическому представлению буквы Z в алфавите ICAO. Определение взято из раздела 2 в [RFC3339], фонетический алфавит описан в документе Международной организации гражданской авиации (International Civil Aviation Organization или ICAO) [ICAO-PA].Time Zone – часовой пояс
Набор правил, представляющих соотношение местного времени и UTC для определённого места или региона. Математически часовой пояс можно представить как функцию, сопоставляющую временные метки со смещением от UTC. Часовой пояс позволяет детерминировано преобразовать временную метку в местное время. Можно применять часовой пояс для обратного преобразования с учётом того, что местное время может иметь несколько разных временных меток вблизи перехода на сезонное время или иных изменений смещения от UTC для данного часового пояса. В отличие от смещения от UTC во временной метке, где не принимается каких-либо допущений о смещении от UTC других связанных временных меток (что не позволяет применять его для операций с локальным временем, таких как «на 1 день позже»), часовой пояс определяет также способ получения новых временных меток на основе разницы в местном времени. Например, для расчёта времени «на один день позже данной метки в Сан-Франциско (Калифорния), нужен часовой пояс, поскольку смещение от UTC местного времени в Сан-Франциско может меняться от одного дня к другому.IANA Time Zone – часовой пояс IANA
Именованный часовой пояс, включенный в базу данных часовых поясов (Time Zone Database), часто обозначаемую tz или zoneinfo, которые поддерживает IANA [TZDB] [BCP175]. Большинство часовых поясов IANA названо по крупнейшему городу определённого региона в рамках одним правил часового пояса, например, Europe/Paris или Asia/Tokyo [TZDB-NAMING]. Правила, заданные для именованных часовых поясов IANA, могут меняться с течением времени. Использование именованных часовых поясов IANA предполагает следование правилам, действующим на момент интерпретации. Дополнительные сведения, передаваемые с использованием имён часовых поясов меняются при изменении правил, занесённом в IANA Time Zone Database.Offset Time Zone – часовой пояс со смещением
Часовой пояс, указанный конкретным смещением от UTC (например, +08:45) и сериализованный с использованием в качестве имени того же формата численного смещения от UTC, который применяется во временной метке [RFC3339], например, 2022-07-08T00:14:07+08:45[+08:45] Смещение в суффиксе, не повторяющее смещение во временной метке, является несогласованным (см. параграф 3.4). Хотя сериализация часовых поясов со смещением поддерживается в этом документе для совместимости с прежними версиями java.time.ZonedDateTime [JAVAZDT], использовать часовые пояса со смещением настоятельно не рекомендуется. В частности, программам недопустимо копировать смещение от UTC из метки в смещение часового пояса для выполнения требования других программ, которым нужен на входе суффикс часового пояса. Это будет приводить к некорректному допущению о неисзменности смещения от UTC временных меток в данном месте, что может привести к ошибкам расчётов в программах, которые выводят временные метки из полученных путём сложения, вычитания или иных операций. Например, 2020-01-01T00:00+01:00[Europe/Paris] позволяет программам добавить шесть месяцев к временной метке с поправкой на летнее время. Однако такой же расчёт, применённый к 2020-01-01T00:00+01:00[+01:00], даст некорректный результат, который будет отставать на 1 час от времени часового пояса Europe/Paris.CLDR
Common Locale Data Repository [CLDR] – проект консорциума Unicode для предоставления приложениям данных о локальных настройках (locale data).Дополнительные сведения о шкалах времени приведены в Приложении E к [RFC1305], разделе 3 в [ISO8601:1988] и соответствующих документах ITU [ITU-R-TF.460-6] (отметим, что [RFC1305] был заменён [RFC5905], где нет приложения E, упомянутого здесь).
2. Обновление RFC 3339
2.1. Основания
В параграфе 4.3 [RFC3339] сказано, что смещение, указанное как Z или +00:00, предполагает, что «UTC является предпочтительной точкой отсчёта для указанного времени». Смещение -00:00 указывает, что «известно время UTC, но неизвестно смещение локального времени».
Это соглашение отражает похожее соглашение для сведений о дате и времени в сообщениях электронной почты, описанное в параграфе 3.3 [RFC5322] и введённое ранее в параграфе 3.3 [RFC2822]. Это соглашение для заголовков электронной почты применяется на практике, тогда как его адаптация в [RFC3339] всегда оставалась затруднительной из-за того, что [ISO8601:2000] и более поздние версии фактически не допускают использование -00:00.
Поэтому реализации, которым нужно выразить семантику -00:00, обычно использовали вместо этого Z.
2.2. Изменения в RFC 3339
Эта спецификация обновляет параграф 4.3 в [RFC3339], приводя его в соответствие с фактической практикой интерпретации смещения Z как -00:00: «известно время UTC, но неизвестно смещение локального времени».
Параграф 4.3 в [RFC3339] в новой редакции следует представлять как указано ниже.
Если известно время в UTC, но смещение местного времени не известно, это может быть представлено как смещение Z (в исходной спецификации для этого указано смещение -00:00, которое не разрешено в [ISO8601:2000] и поэтому не обеспечивает функциональной совместимости; в параграфе 3.3 [RFC5322] описано похожее соглашение для электронной почты, которое не вызывает проблем). Семантически это отличается от смещения +00:00, которое предполагает, что UTC является предпочтительной точкой отсчёта для указанного времени.
2.3. Примечания
Отметим, что семантика локального смещения +00:00 не изменилась, оно по-прежнему означает, что UTC является предпочтительной точкой отсчёта для указанного времени.
Отметим также, что факт запрета в [ISO8601:2000] и последующих вресиях стандарта использовать -00:00 в качестве локального смещения снижает функциональную совместимость, которая может обесчпечиваться при использовании этого свойства, однако данная спецификация формально не запрещает этот синтаксис. С учётом обновления [RFC3339] вместо этого следует применять суффикс локального смещения Z.
3. Расширенный формат даты и времени в Internet (IXDTF)
В этом разделе обсуждаются желаемые качаства суффикса расширения временных меток и определяется формат IXDTF, расширяющий [RFC3339] для использования в протоколах Internet.
3.1. Формат расширенной информации
Формат позволяет приложениям добавлять дополнительные важные сведения к обычным временным меткам [RFC3339]. Это делается путём определения тегов с ключом и значением через знак равенства (=). Значением тега может быть один или несколько элементов, разделённых символом дефиса (знака вычитания). Приложения могут создавать информационные суффиксы временных меток с любым числом таких тегов. В ключах используются только символы нижнего регистра. В значениях регистр символов учитывается, если не указано иное. Обработка несогласованных сведений в суффиксах рассматривается в параграфе 3.3.
3.2. Ключи регистрации для тегов расширенной информации
Ключи тегов суффиксов регистрируются с предоставлением сведений, указанных в этом параграфе. Эта информация задана по образу используемой в реестре Media Types [RFC6838] и при возникновении сомнений следует применять положения для этого реестра.
Key Identifier
Ключ (в соответствии с suffix-key из параграфа 4.1).Registration Status
Статус регистрации – временная (Provisional) или постоянная (Permanent).Description
Очень краткое описание ключа.Change Controller
Контролёр изменений – лицо, отвечающее за спецификацию, регулирующую значения этого ключа. Эти сведения могут включать адрес электронной почты, списки рассылки или ссылки на соответствующие web-страницы (URL).Reference
Указание документа. Для ключей постоянных тегов указывается полная спецификация, для временных тегов предполагается, что доступны некоторые сведения, даже если они не соответствуют полной спецификации (в этом случае предполагается, что регистрирующая сторона со временем уточнит сведения).Имена ключей, начинающиеся с символа подчёркивания (_), предназначены для экспериментов в контролируемых средах и не могут регистрироваться. Такие ключи недопустимо использовать для обмена и они должны отвергаться реализациями, не включёнными в такие эксперименты. Опасности утечки экспериментальных ключей в среды общего пользования и необходимости предотвращения таких утечек таких утечек рассматриваются в [BCP178].
3.3. Необязательность, выборочность и критичность тегов
Для формата IXDTF суффиксные теги не являются обязательными и создатель строки может добавлять их по своему разумению. Тем не менее, приложение может требовать наличия таких тегов.
Без дополнительных указаний суффиксные теги являются выборочными и получатель может игнорировать любой такой тег, включенный в строку IXDTF. Причина игнорирования может состоять в том, что получатель не реализует (не знает) конкретный ключ суффикса или понимает ключ, но не может действовать в соответствии с его значением.
Суффиксный тег может указывать свою критичность. Это говорит получателю, что недопустимо действовать со строкой IXDTF, пока не обработан указанный тег. Критичный суффиксный тег указывается восклицательным знаком (!) после открывающей скобки (см. critical-flag в параграфе 4.1).
Строка IXDTF вида 2022-07-08T00:14:07+01:00[Europe/Paris] внутренне противоречива (см. параграф 3.4), поскольку Europe/Paris не использует часовой пояс со смещением +01:00 в июле 2022 г. Однако подсказка часового пояса в суффиксном теге является выборочной и получатель не обязан реагировать на несоответствие, он может рассматривать строку IXDTF как 2022-07-08T00:14:07+01:00
В соответствии с разделом 2 (см. также параграф 3.4) строка IXDTF 2022-07-08T00:14:07Z[Europe/Paris] не показывает несоответствия, поскольку локальное смещение Z не предполагает конкретного часого пояса при интерпретации. Применение правил Time Zone Database для Europe/Paris летом 2022 делает её эквивалентом 2022-07-08T02:14:07+02:00[Europe/Paris]
Неизвестный суффикс вида 2022-07-08T00:14:07+01:00[knort=blargel] можно игнорировать полностью (в предположении непонимания ключа knort).
В отличие от избирательного использования суффксного тена строки вида
2022-07-08T00:14:07+01:00[!Europe/Paris] 2022-07-08T00:14:07Z[!u-ca=chinese][u-ca=japanese] 2022-07-08T00:14:07Z[u-ca=chinese][!u-ca=japanese] 2022-07-08T00:14:07Z[!knort=blargel]
имеют внутреннее несоответствие или непонятную пару ключ-значение, которые помечены как критические, и получатель должен считать эти строки IXDTF ошибочными. Это означает, что приложение должно отвергнуть данные или выполнить иную обработку ошибок, например, спросить у пользователя, как следует реагировать (см. параграф 3.4).
Отметим, что приложения могут выполнять дополнительную обработку несогласованных или нераспознанных выборочных суффиксных тегов, например, спрашивать у пользователя, как устранить несоответствие. Этого не требуется для выборочных тегов, но требуется для отклонения или выполнения специальной обработки несогласованных или нераспознанных тегов, которые помечены как критические.
Приложение, встретившее дубликат выборочного суффиксного тега и нежелающее дополнительно обрабатывать это несоответствие, должно выбрать первый суффикс с дублирующимся ключом, т. е. метки
2022-07-08T00:14:07Z[u-ca=chinese][u-ca=japanese] 2022-07-08T00:14:07Z[u-ca=chinese]
будут считаться одинаковыми.
3.4. Несогласованность time-offset и сведений о часовом поясе
Временная метка [RFC3339] может включать значение time-offset, указывающее разницу между местным временем и UTC (см. раздел 4 в [RFC3339] с учётом изменений, внесённых в разделе 2 этой спецификации в параграф 4.3 [RFC3339]). Сведения, указанные значением time-offset, могут не соответствовать информации, представленной суффиксом часового пояса для метки IXDTF. Например, приложение-календарь может хранить строку IXDTF, представляющую встречу в далёком будущем в определённом часовом поясе. Если затем определение часового пояса будет изменено, исходно согласованные строки IXDTF могут стать несогласованными.
При установленном флаге критичности и несоответствии time-offset суффиксу часового пояса приложение должно реагировать на несоответствие. Если флаг критичности не установлен, приложение может реагировать на несоответствие. Реакция на несоответствие может включать отклонение временной метки или устранение несоответствия с использованием дополнительной информации, например, ввода данных от пользователя или запрограммированного поведения.
Временные метки IXDTF на рисунке 1 представляют время 00:14:07 UTC, указывая местное время с time-offset +00:00. Однако в часовом поясе Europe/London в июле 2022 г. используется смещение +01:00, поэтому временные метки будут несогласованными, причём в первом случае приложение должно реагировать на несоответствие (критический суффикс часового пояса), а во втором – может реагировать на несоответствие (выборочный суффикс).
В
2022-07-08T00:14:07+00:00[!Europe/London] 2022-07-08T00:14:07+00:00[Europe/London]
Рисунок . Несогласованность меток IXDTF.
соответствии с параграфом 4.3 [RFC3339], обновлённым в разделе 2, временные метки IXDTF могут не включать сведения о местном времени в часть [RFC3339], просто используя Z вместо числового смещения часового пояса. Временные метки IXDTF на рисунке 2 (то же время, что и в строках рисунка 1) являются несогласованными, поскольку они не указывают ни местного времени, ни местного смещения в своей части [RFC3339]. Приложения, получающие такие строки, могут местное смещение и время, используя правила для суффикса часового пояса. Например, суффикс Europe/London на рисунке 2 (как и на рисунке 1), может быть помечен как критический (т. е. приложение должно понимать сведения о часовом поясе) или является выборочным, представляющим лишь дополнительные сведения.
О
2022-07-08T00:14:07Z[!Europe/London] 2022-07-08T00:14:07Z[Europe/London]
Рисунок . Согласованность меток IXDTF.
тметим, что вместо Z можно использовать -00:00, поскольку они имеют одинаковый смысл в соответствии с разделом 2, но [ISO8601:2000] не разрешает -00:00, поэтому предпочтительно использовать Z.
4. Синтаксические расширения RFC 3339
4.1. ABNF
Ниже приведены правила, расширяющие синтаксис ABNF, заданный в [RFC3339], для включения необязательного суффикса. Расширенный формат дат и времени Internet (IXDTF) описывается правилом date-time-ext. Элементы date-time и time-numoffset взяты из параграфа 5.6 в [RFC3339], а ALPHA и DIGIT из Приложения B.1 к [RFC5234].
time-zone-initial = ALPHA / "." / "_"
time-zone-char = time-zone-initial / DIGIT / "-" / "+"
time-zone-part = time-zone-initial *time-zone-char
; но не . или ..
time-zone-name = time-zone-part *("/" time-zone-part)
time-zone = "[" critical-flag
time-zone-name / time-numoffset "]"
key-initial = lcalpha / "_"
key-char = key-initial / DIGIT / "-"
suffix-key = key-initial *key-char
suffix-value = 1*alphanum
suffix-values = suffix-value *("-" suffix-value)
suffix-tag = "[" critical-flag
suffix-key "=" suffix-values "]"
suffix = [time-zone] *suffix-tag
date-time-ext = date-time suffix
critical-flag = [ "!" ]
alphanum = ALPHA / DIGIT
lcalpha = %x61-7A
Рисунок . Грамматика ABNF для расширений RFC 3339.
Отметим, что time-zone и suffix-tag синтаксически похожи но первый не включает знака равенства (=). Этот особый случай доступен лишь для тегов часовых поясов.
Определению ABNF для time-zone-part соответствуют «.» и «..», которые явно исключены (см. примечание для time-zone-part).
Элемент time-zone-name предназначен быть именем IANA Time Zone. Поскольку генератор и получатель могут использовать разные версии Time Zone Database, получатели могут не знать имени IANA Time Zone и им следует рассматривать такие ситуации как любые другие несоответствия.
Примечание. На момент создания документа размер time-zone-part был ограничен 14 символами правилами из [TZDB-NAMING]. Одна платформа может соблюдать это ограничение, а другая использовать более длинные имена. Поскольку time-zone-name в конечном итоге приходится искать в локальной базе данных, создание time-zone-part на рисунке 3 намеренно сделано разрешительным.
4.2. Примеры
В этом параграфе приведены некоторые примеры расширенного формата дат и времени Internet (IXDTF).
Н
1996-12-19T16:39:57-08:00
Рисунок . Дата и время RFC 3339 со смещением часового пояса.
а рисунке 4 представлен момент 39 минут 57 секунд после 16 часов 19 декабря 1996 г. со смещением -08:00 от UTC. Отметим, что это совпадает с моментом 1996-12-20T00:39:57Z, выраженным в UTC.
Н
1996-12-19T16:39:57-08:00[America/Los_Angeles]
Рисунок . Добавление имени часового пояса.
а рисунке 5 представлен тот же момент, но дополнительно указан связанный с ним часовой пояс (Pacific Time), который принимают во внимание осведомленные о часовых поясах приложения.
Н
1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]
Рисунок . Проектирование для еврейского календаря.
а рисунке 6 представлен тот же момент, но он информирует осведомленные о календаре приложения (см. раздел 5), что им следует отображать это время на еврейский календарь.
Н
1996-12-19T16:39:57-08:00[_foo=bar][_baz=bat]
Рисунок . Добавление экспериментальных тегов.
а рисунке 7, основанном на рисунке 4, используются ключи, указанные как экспериментальные символом подчёркивания (_) в начале, для объявления двух дополнительных информационных элементов в суффиксе. Они могут интерпретироваться реализациями, участвующими в эксперименте с использованием этих ключей тегов.
5. Ключ u-ca – осведомлённость о календаре
Суффикс u-ca предназначен для указания календаря, предпочтительного для представления даты и времени. Календарь – это набор правил, определяющих учёт и использование дат реализациями. Набор значений суффиксов, разрешённых для этого ключа – это значения, определённые для идентификатора календаря Unicode (Calendar Identifier) [TR35]. В [CLDR-LINKS] приведены ссылки на наиболее свежие данные о [CLDR], как стабильные, так и находящиеся в разработке.
6. Взаимодействие с IANA
Агентство IANA создало реестр Timestamp Suffix Tag Keys в новой группе реестров Internet Date/Time Format. В каждую запись реестра следует включать сведения, указанные в параграфе 3.2. Исходное содержимое реестра приведено в таблице 1.
Таблица . Исходное содержимое реестра Timestamp Suffix Tag Keys.
|
Идентификатор ключа |
Статус регистрации |
Описание |
Контролёр изменений |
Документ |
|---|---|---|---|---|
|
u-ca |
постоянная |
Предпочтительный календарь для представления |
IETF |
раздел 5 в RFC 9557 |
Регистрация выполняется по процедуре Specification Required [BCP26] для постоянных записей и Expert Review – для временных. В последнем случае экспертам следует убедиться в наличии базовой спецификации, даже если она ещё не опубликована. Экспертам также следует экономно распределять идентификаторы ключей, указывающих на общеприменимую семантику, сохраняя их в резерве для случаев потенциально широкого использования, когда могут обеспечиваться преимущества за счёт коротких ключей. Если эксперты узнают о внедрении и использовании ключа, они могут сами инициировать регистрацию, чтобы предотвратить возможные в будущем конфликты.
7. Вопросы безопасности
7.1. Избыточное раскрытие
Возможность включать во временные метки различные элементы дополнительной информации может приводить к избыточному раскрытию, пример чего представлен в разделе 7 [RFC3339]. Раскрытие сведений о календарной системе или выбранном языке может давать больше информации о создателе временной метки, чем разрешает принцип минимизации данных [DATA-MINIMIZATION]. В более общем смысле создателям временных меток IXDTF нужно рассмотреть уместность раскрытия информации во временных метках получателям и принять решение о минимизации такого раскрытия, если получатели меток не находятся под контролем их создателя.
7.2. Уязвимости реализаций формата данных
Как обычно, расширение синтаксиса формата данных может приводить к новым уязвимостям реализаций, анализирующих и обрабатывающих формат. Для IXDTF не известно о ситуациях, ведущих к необычным проблемам.
7.3. Работа с несогласованными данными
Сведения в разных частях строки IXDTF могут быть противоречивыми в расширениях, заданных этой спецификацией (см., например, параграф 3.4), и в будущих расширениях. Когда соображения безопасности требуют согласованной интерпретации несколькими участниками (например, при встраивании временных меток в качестве параметров контроля доступа), можно внедрять лишь расширения, имеющие хорошо понятное и совместно используемое устранения таких несоответствий.
8. Литература
8.1. Нормативные документы
[BCP175] Best Current Practice 175, <https://www.rfc-editor.org/info/bcp175>. На момент написания этого документа: Lear, E. and P. Eggert, “Procedures for Maintaining the Time Zone Database”, BCP 175, RFC 6557, DOI 10.17487/RFC6557, February 2012, <https://www.rfc-editor.org/info/rfc6557>.
[BCP178] Best Current Practice 178, <https://www.rfc-editor.org/info/bcp178>. На момент написания этого документа: Saint-Andre, P., Crocker, D., and M. Nottingham, “Deprecating the “X-” Prefix and Similar Constructs in Application Protocols”, BCP 178, RFC 6648, DOI 10.17487/RFC6648, June 2012, <https://www.rfc-editor.org/info/rfc6648>.
[BCP26] Best Current Practice 26, <https://www.rfc-editor.org/info/bcp26>. На момент написания этого документа: Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps”, RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC5234] Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, “Media Type Specifications and Registration Procedures”, BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Дополнительная литература
[CLDR] Unicode CLDR, “Unicode CLDR Project”, <https://cldr.unicode.org>.
[CLDR-LINKS] Unicode CLDR, “Stable Links Info”, <https://cldr.unicode.org/stable-links-info>.
[DATA-MINIMIZATION] Arkko, J., “Emphasizing data minimization among protocol participants”, Work in Progress, Internet-Draft, draft-arkko-iab-data-minimization-principle-05, 10 July 2023, <https://datatracker.ietf.org/doc/html/draft-arkko-iab-data-minimization-principle-05>.
[ICAO-PA] International Civil Aviation Organization, “Annex 10 to the Convention on International Civil Aviation: Aeronautical Telecommunications; Volume II Communication Procedures including those with PANS status”, 7th ed., July 2016, <https://store.icao.int/annex-10-aeronautical-telecommunications-volume-ii-communication-procedures-including-those-with-pans-status>.
[IERS] IERS, “International Earth Rotation Service Bulletins”, <https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html>.
[ISO8601-1:2019] ISO, “Date and time — Representations for information interchange — Part 1: Basic rules”, ISO 8601-1:2019, February 2019, <https://www.iso.org/standard/70907.html>.
[ISO8601:1988] ISO, “Data elements and interchange formats – Information interchange — Representation of dates and times”, ISO 8601:1988, June 1988, <https://www.iso.org/standard/15903.html>. Also available from <https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub4-1-1991.pdf>.
[ISO8601:2000] ISO, “Data elements and interchange formats – Information interchange — Representation of dates and times”, ISO 8601:2000, December 2000, <https://www.iso.org/standard/26780.html>.
[ITU-R-TF.460-6] ITU-R, “Standard-frequency and time-signal emissions”, ITU-R Recommendation TF.460-6, February 2002, <https://www.itu.int/rec/R-REC-TF.460/en>.
[JAVAZDT] Oracle, “Class DateTimeFormatter: ISO_ZONED_DATE_TIME”, <https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html#ISO_ZONED_DATE_TIME>.
[RFC1305] Mills, D., “Network Time Protocol (Version 3) Specification, Implementation and Analysis”, RFC 1305, DOI 10.17487/RFC1305, March 1992, <https://www.rfc-editor.org/info/rfc1305>.
[RFC2822] Resnick, P., Ed., “Internet Message Format”, RFC 2822, DOI 10.17487/RFC2822, April 2001, <https://www.rfc-editor.org/info/rfc2822>.
[RFC5322] Resnick, P., Ed., “Internet Message Format”, RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, “Network Time Protocol Version 4: Protocol and Algorithms Specification”, RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[TR35] Davis, M., Ed., “Unicode Technical Standard #35: Unicode Locale Data Markup Language (LDML)”, <https://www.unicode.org/reports/tr35/#UnicodeCalendarIdentifier>.
[TZDB] IANA, “Time zone and daylight saving time data”, <https://data.iana.org/time-zones/tz-link.html>.
[TZDB-NAMING] IANA, “Theory and pragmatics of the tz code and data”, <https://data.iana.org/time-zones/theory.html>.
Благодарности
Эта спецификация использует результаты ECMA TC39, в частности для предложения Temporal (временное).
Richard Gibson и Justin Grant внесли редакторские улучшения. Руководители рабочей группы SEDATE Chairs Mark McFadden и Bron Gondwana (последний также был руководителем CALEXT) помогли организовать структуры, нужные для работы в среде с несколькими SDO. John Klensin критически отнёсся к разработке этой спецификации, что привело к её существенному улучшению. Авторы особенно признательны Francesca Palombini за её общее руководство и рецензию AD.
Участник работы
Justin Grant Email: justingrant.ietf.public@gmail.comАдреса авторов
Ujjwal Sharma Igalia, S.L. Bugallal Marchesi, 22, 1º 15008 A Coruña Spain Email: ryzokuken@igalia.com Carsten Bormann Universität Bremen TZI Postfach 330440 D-28359 Bremen Germany Phone: +49-421-218-63921 Email: cabo@tzi.orgПеревод на русский язык
1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.