✘NTS and ALPN

[Achim Gratz]

Gary E. Miller via devel writes:
>>  Dan's patch removed
>> collapsed the internal list to a single element that is already
>> stripped of its length byte,
>
> Yes.  That was intentional.

As a hotpatch (and demonstration oof the issue) it's OK, as a longterm
fix not.  All IMHO of course.  Btw, I'd expect a decent compiler to
optimize the inner loop away as it's all based on static data.

>> so it doesn't conform to the ALPN data
>> structure description anymore.
>
> Already discussed here.  Right or wrong, NTS was not compatible with
> the other NTS implementations.  Dan's patch makes NTS compatible.

As does mine.

> If all the other NTS are doing it wrong, then you need to take it up
> with them.

NTPsec was doing the wrong thing, and nobody but you insisted otherwise.

>> Consequently it also omits any code
>> to traverse the internal list, both of which will come back to bite
>> you when you do need to support the second protocol.
>
> Are there any plans for that?  I don't remember hearing any.  No
> need for code to implement some vauge future possible change.

Yes.  The currently supported protocol is "ntpsec/1", which is not yet
frozen in fact.  That will change as soon as that RFC is accepted and
then any changes or extensions will need to define a new protocol
version.

>> The previous changes introduced by Hal also check for things that the
>> API clearly state need not be checked (there is explicit guidance that
>> the callback we implement can assume the syntactic structure of the
>> input data is correct).
>
> Hal had weeks to look at it.  Did he miss something?

I'm not making any guesses about other folks' state of mind, just
pointing out what I see in the code.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra