Network Working Group T. Lüchow Internet-Draft Dorfzwockel Intended status: Experimental 24 August 2026 Expires: 25 February 2027 Route86: A Compact Context-Dependent Timestamp Format draft-luechow-route86-timestamp-01 Abstract This document specifies Route86, a compact textual timestamp format for constrained message transports. A Route86 value consists of a three-character Base36 calendar-day component and a three-digit decimal time-of-day component. The canonical representation occupies exactly six ASCII characters. The calendar component is interpreted relative to an external reference date. The reference date itself encodes as AAA. The time- of-day component divides a fixed BMT day, defined here as UTC+01:00 without daylight-saving adjustment, into 1000 intervals of 86.4 seconds. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 25 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Lüchow Expires 25 February 2027 [Page 1] Internet-Draft Route86 Timestamp August 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Timestamp Format . . . . . . . . . . . . . . . . . . . . . . 3 4. Temporal Reference and BMT Normalization . . . . . . . . . . 3 5. Reference Date . . . . . . . . . . . . . . . . . . . . . . . 4 6. Calendar-Day Component . . . . . . . . . . . . . . . . . . . 4 7. Time-of-Day Component . . . . . . . . . . . . . . . . . . . . 5 7.1. Leap Seconds . . . . . . . . . . . . . . . . . . . . . . 5 8. Encoding Algorithm . . . . . . . . . . . . . . . . . . . . . 6 9. Decoding Algorithm . . . . . . . . . . . . . . . . . . . . . 6 10. Canonical Representation . . . . . . . . . . . . . . . . . . 7 11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1. Calendar-Day Vectors . . . . . . . . . . . . . . . . . . 8 11.2. Time-of-Day Vectors . . . . . . . . . . . . . . . . . . 8 11.3. Complete Example . . . . . . . . . . . . . . . . . . . . 9 12. Use in Message Entities . . . . . . . . . . . . . . . . . . . 9 13. Precision, Intervals, and Ordering . . . . . . . . . . . . . 9 14. Application Profiles and Salted Reference Dates . . . . . . . 10 15. Security Considerations . . . . . . . . . . . . . . . . . . . 10 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 17. Normative References . . . . . . . . . . . . . . . . . . . . 10 18. Informative References . . . . . . . . . . . . . . . . . . . 11 Appendix A. Changes from -00 . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Conventional textual timestamps can be large relative to the payload of constrained transports. Route86 defines a six-character representation that deliberately exchanges universal self-description for compactness. Interpretation requires a reference date known to both encoder and decoder. That reference date is external to the six-character value and may be fixed by an application profile, derived from registration context, or otherwise selected by the communicating parties. Lüchow Expires 25 February 2027 [Page 2] Internet-Draft Route86 Timestamp August 2026 Route86 is not a replacement for a general Internet timestamp format. It is intended for contexts in which compactness, a shared reference context, and approximately minute-scale time resolution are acceptable. 2. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Timestamp Format A canonical Route86 timestamp consists of exactly six ASCII characters: DDDBBB DDD is the calendar-day component. BBB is the time-of-day component. No separator occurs between them. The syntax is described using ABNF [RFC5234]: route86 = day-component beat-component day-component = 3base36 beat-component = 3DIGIT base36 = DIGIT / %x41-5A The base36 rule admits only ASCII digits and uppercase ASCII letters A through Z. Thus the ABNF describes canonical values only. 4. Temporal Reference and BMT Normalization Route86 evaluates both the calendar day and the time of day in a single common reference offset. This document defines that offset as UTC+01:00, corresponding to Biel Mean Time (BMT) as used by Internet Time [SWATCH]. BMT in Route86 is a fixed offset. Daylight-saving time is not applied. An encoder receiving an instant expressed in another offset MUST first convert that instant to UTC+01:00. The BMT civil date produced by that conversion is used for DDD, and the BMT time of day from the same conversion is used for BBB. Lüchow Expires 25 February 2027 [Page 3] Internet-Draft Route86 Timestamp August 2026 If an input value does not identify an absolute instant, for example because it contains a local clock time without an offset or equivalent timezone context, an application profile MUST supply the missing context before Route86 encoding. 5. Reference Date The Route86 calendar component is relative to a reference date that is external to the six-character timestamp. A receiver MUST know the applicable reference date before interpreting DDD. The reference date is a civil date in the proleptic Gregorian calendar as observed in BMT. It has no time-of-day component. This document uses 1970-01-01 as the reference date in examples. Applications MAY use another reference date. The reference date itself has a day difference of zero and therefore encodes as AAA. Calendar-day counting is not inclusive. 6. Calendar-Day Component Let target_date be the BMT civil date obtained after the normalization in Section 4. Let reference_date be the shared Route86 reference date. The signed calendar-day difference is: day_delta = target_date - reference_date The subtraction is the difference in proleptic-Gregorian ordinal dates. Consequently, the reference date has day_delta = 0, the immediately preceding date has day_delta = -1, and the immediately following date has day_delta = 1. Route86 then applies the decimal offset 13330: route86_day = day_delta + 13330 The value 13330 is chosen because: AAA(base36) = 13330(decimal) route86_day MUST be in the inclusive range 0 through 46655. Values outside that range are not representable by this version of Route86 and MUST be rejected. Lüchow Expires 25 February 2027 [Page 4] Internet-Draft Route86 Timestamp August 2026 The corresponding representable day_delta range is therefore -13330 through +33325 days. The integer route86_day is encoded in Base36 using the alphabet: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ The result MUST be left-padded with 0 characters to exactly three characters. Encoders MUST emit uppercase ASCII letters. 7. Time-of-Day Component Route86 divides each nominal BMT day into 1000 equal intervals. Each interval is 86.4 seconds long. Let s be the exact number of elapsed seconds since BMT midnight, including any fractional part, with: 0 <= s < 86400 The beat number is: beat = floor(s * 1000 / 86400) This is equivalent to floor(s / 86.4). The mathematical floor operation is normative. Implementations SHOULD avoid binary floating-point boundary errors, for example by using integer or rational arithmetic when the source timestamp provides subsecond precision. The result is an integer in the range 0 through 999 and MUST be encoded as exactly three decimal digits, left-padded with zeroes as necessary. 0 -> 000 7 -> 007 42 -> 042 382 -> 382 999 -> 999 The commercial @ notation associated with Internet Time is not part of Route86. 7.1. Leap Seconds Route86 models a nominal day as exactly 86400 seconds and has no distinct lexical representation for a leap-second label such as 23:59:60. Lüchow Expires 25 February 2027 [Page 5] Internet-Draft Route86 Timestamp August 2026 An encoder presented with a timestamp containing a leap-second label MUST NOT encode that label directly. The application MAY normalize such an input before Route86 encoding if its profile defines an unambiguous mapping. Applications that need to preserve leap-second identity MUST NOT rely on Route86 as their sole timestamp representation. 8. Encoding Algorithm Given an absolute input instant and a shared reference date, an encoder performs the following steps: 1. Convert the input instant to the fixed offset UTC+01:00 (BMT). 2. Extract the BMT civil date and the exact elapsed seconds since BMT midnight. 3. Compute day_delta as the BMT target date minus the reference date. 4. Compute route86_day = day_delta + 13330. Reject the input if the value is outside 0 through 46655. 5. Encode route86_day as three uppercase Base36 characters, left- padding with 0 when needed. 6. Compute beat = floor(s * 1000 / 86400). 7. Encode beat as three decimal digits, left-padding with 0 when needed. 8. Concatenate the two components without a separator. 9. Decoding Algorithm Given a canonical Route86 value and the applicable reference date, a decoder performs the following steps: 1. Validate the six-character grammar in Section 3. 2. Decode DDD as an unsigned Base36 integer route86_day. 3. Compute day_delta = route86_day - 13330. 4. Add day_delta Gregorian calendar days to the reference date to obtain the BMT civil date. 5. Decode BBB as decimal integer beat. Lüchow Expires 25 February 2027 [Page 6] Internet-Draft Route86 Timestamp August 2026 6. Interpret the time component as the half-open interval beginning at beat * 86.4 seconds after BMT midnight and ending at (beat + 1) * 86.4 seconds after BMT midnight. For beat = 999, the end of the half-open interval is the following BMT midnight. Route86 does not define a representative point within the decoded interval. An application that needs one, such as the interval start or midpoint, MUST define that convention separately. 10. Canonical Representation A canonical Route86 timestamp: * MUST contain exactly six ASCII characters; * MUST contain three Base36 characters followed by three decimal digits; * MUST use uppercase letters in the Base36 component; * MUST NOT contain whitespace or separators; * MUST NOT contain an @ character; and * SHOULD be transported and stored as an opaque six-character string. Protocol decoders MUST reject characters outside the grammar. User- interface implementations MAY accept lowercase letters for convenience, but such input is non-canonical and MUST be converted to uppercase before storage, comparison, or protocol use. The following value is canonical: Q8S382 The following values are not canonical: q8s382 Q8S@382 Q8S-382 Q8S 382 Lüchow Expires 25 February 2027 [Page 7] Internet-Draft Route86 Timestamp August 2026 11. Test Vectors This section is normative with respect to the arithmetic demonstrated by the vectors. 11.1. Calendar-Day Vectors Using the reference date 1970-01-01: +=================+===========+===============+=====+ | Target BMT date | day_delta | Decimal value | DDD | +=================+===========+===============+=====+ | 1933-07-04 | -13330 | 0 | 000 | +-----------------+-----------+---------------+-----+ | 1969-12-31 | -1 | 13329 | AA9 | +-----------------+-----------+---------------+-----+ | 1970-01-01 | 0 | 13330 | AAA | +-----------------+-----------+---------------+-----+ | 1970-01-02 | 1 | 13331 | AAB | +-----------------+-----------+---------------+-----+ | 2026-08-17 | 20682 | 34012 | Q8S | +-----------------+-----------+---------------+-----+ | 2061-03-29 | 33325 | 46655 | ZZZ | +-----------------+-----------+---------------+-----+ Table 1: Calendar-day vectors 11.2. Time-of-Day Vectors +==============+=================+=====+ | BMT time | Elapsed seconds | BBB | +==============+=================+=====+ | 00:00:00 | 0 | 000 | +--------------+-----------------+-----+ | 00:01:26.399 | 86.399 | 000 | +--------------+-----------------+-----+ | 00:01:26.400 | 86.4 | 001 | +--------------+-----------------+-----+ | 09:10:10 | 33010 | 382 | +--------------+-----------------+-----+ | 23:59:59 | 86399 | 999 | +--------------+-----------------+-----+ Table 2: BMT beat vectors Lüchow Expires 25 February 2027 [Page 8] Internet-Draft Route86 Timestamp August 2026 11.3. Complete Example With reference date 1970-01-01, the instant 2026-08-17T10:10:10+02:00 first normalizes to 2026-08-17T09:10:10+01:00 BMT. Reference date: 1970-01-01 Input instant: 2026-08-17T10:10:10+02:00 BMT instant: 2026-08-17T09:10:10+01:00 day_delta: 20682 route86_day: 34012 DDD: Q8S BBB: 382 Route86 timestamp: Q8S382 Encoded length: 6 octets 12. Use in Message Entities A Route86 timestamp MAY be used as the temporal component of a message entity or identifier. A Route86 value MUST NOT be assumed to be globally unique. Applications requiring uniqueness MUST combine it with additional context, such as an origin identifier, recipient identifier, nonce, sequence value, or cryptographic identifier. A tuple consisting of origin context, recipient context, and Route86 value is one possible application-level construction, but this document does not standardize such a tuple. 13. Precision, Intervals, and Ordering The time-of-day component has a nominal resolution of 86.4 seconds. Route86 MUST NOT be used as the sole representation where second- level timestamp precision is required. Within one shared reference-date context, canonical Route86 strings sort chronologically in ascending ASCII lexicographic order. This follows from the fixed-width Base36 day component, the value order of the canonical Base36 alphabet, and the fixed-width decimal beat component. This ordering property does not apply across values interpreted with different reference dates. Lüchow Expires 25 February 2027 [Page 9] Internet-Draft Route86 Timestamp August 2026 14. Application Profiles and Salted Reference Dates An application profile MAY select a fixed reference date, negotiate a reference date, derive it from registration state, or use a salted reference date. A profile that does not use a universally fixed reference date SHOULD specify how the date is established, how long it remains valid, and what happens when a target date falls outside the representable Route86 range. Policies that restrict the age or placement of a reference date are application-level rules and are not part of the Route86 wire format. 15. Security Considerations Route86 is an encoding format. It provides no confidentiality, integrity, authentication, authorization, or replay protection. A salted reference date can obscure casual interpretation of a timestamp, but it MUST NOT be treated as a cryptographic secret or security boundary. Candidate date ranges are commonly small enough to permit exhaustive guessing, especially when an attacker has approximate knowledge of the encoded date. Protocols requiring authenticated or integrity-protected timestamps MUST provide those properties independently of Route86. Implementations comparing Route86 values from untrusted sources MUST ensure that the same reference-date context applies before relying on chronological ordering. 16. IANA Considerations This document has no IANA actions. 17. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Lüchow Expires 25 February 2027 [Page 10] Internet-Draft Route86 Timestamp August 2026 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . 18. Informative References [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [SWATCH] Swatch AG, "Internet Time", Defines the 1000-beat day and identifies BMT as the reference for Internet Time., . Appendix A. Changes from -00 * Clarified that the reference date itself has day_delta = 0 and encodes as AAA. * Defined calendar arithmetic explicitly and established the full representable range 000 through ZZZ. * Specified that both timestamp components are derived after normalization to fixed UTC+01:00 BMT. * Defined the beat calculation using normative mathematical floor semantics. * Specified leap-second behavior. * Added ABNF, explicit encoding and decoding algorithms, and normative test vectors. * Corrected the complete example from Q8T340 to Q8S382. * Clarified that canonical values sort chronologically only within a shared reference-date context. * Separated application-profile policy from the Route86 wire format. * Expanded security considerations and references. * Updated the author's email address. Author's Address Lüchow Expires 25 February 2027 [Page 11] Internet-Draft Route86 Timestamp August 2026 Thomas Lüchow Dorfzwockel Email: dorfzwockel@not4bflu55.de Lüchow Expires 25 February 2027 [Page 12]