[dispatch] Re: Venue guidance for draft-luechow-route86-timestamp-01

[Ted Hardie <[e-mail]>]

Howdy,

The draft mentions constrained environments, but there is no indication of
exactly which environments have these constraints and need these particular
semantics.  Many constrained environments would need more granular
semantics than 86.4 second time-of-day slices, for example, and so would
not be able to use this.  Can you describe the target environments in a bit
more detail?  Without that, it is difficult to know what venue might be
suitable (if any IETF venue turns out to be--this may be work better done
elsewhere).

best regards,

Ted Hardie

On Tue, Sep 15, 2026 at 9:41 AM Thomas Lüchow <dorfzwockel=
[e-mail]> wrote:

> Hello DISPATCH,
>
> I am seeking guidance on the appropriate IETF venue for the following
> individual Internet-Draft:
>
> Route86: A Compact Context-Dependent Timestamp Format
> https://datatracker.ietf.org/doc/draft-luechow-route86-timestamp/
>
> Route86 defines a canonical six-character textual timestamp for constrained
> message transports. It combines a three-character Base36 calendar-day
> component, interpreted relative to an external reference date, with a
> three-digit time-of-day component at 86.4-second resolution.
>
> The proposal is deliberately narrow: it does not define a transport and is
> not intended to replace general-purpose Internet date and time formats. The
> interoperability question is whether independent implementations can
> encode,
> decode, validate, and order Route86 values consistently when they share the
> same application profile and reference-date context.
>
> Would DISPATCH be the appropriate place for initial discussion, or would
> CoRE
> or another existing group be a better fit? If this subject is outside
> DISPATCH's scope, a pointer to the appropriate venue would be appreciated.
>
> My aim is an Experimental specification if there is sufficient interest; I
> am
> not assuming a particular stream or working group.
>
> I can provide a short problem statement, implementation notes, and
> additional
> test vectors if that would be useful.
>
> Best regards,
>
> Thomas Luechow
> Dorfzwockel
> [e-mail]
> _______________________________________________
> dispatch mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>