Re: Microsoft's Thread-Index Field.

[Ken Hornstein]

Ralph,

First, it's good to hear you're alive!  And I mean in that in all
seriousness; none of us are exactly spring chickens anymore, are we?
I hope everyone out there is doing well.

And ... yeah, it pretty much sucks that Outlook is doing it's own
thing here.

>To return any header in a reply, repl(1)'s -form file can have something
>like:
>
>    %<{thread-index}Thread-Index: %{thread-index}\n%>\
>
>Should we modify nmh's standard repl format files to have this?

I think ... yes.  This seems like it is very simple.

>Which leaves supporting generating a new Thread-Index for comp(1), and
>whether that's required.  Or does Outlook add one to every email which
>arrives without one?

I could do some experimentation on that regard using Outlook 365.
Honestly, I think the simplest thing to do is is generate a thread-index
value in mh-format; we don't really have an easy method of encoding
something in base64 in the mh-format language.

As I see it from the helpful references you provided, we need ....

- a single byte containing 0x01
- An 5-byte timestamp which is ... the number of 100-nanosecond intervals
  since January 1st, 1601 (the upper 5 bytes of that value).  And it seems
  like the timestamp doesn't actually matter as Bugzille uses a fixed
  timestamp.
- A 16-byte GUID.  Which basically can be random bytes (I know technically
  GUIDs are not, but it seems like they don't care).

--Ken