Hal Murray <hmur...@megapathdsl.net>:
>
> e...@thyrsus.com said:
> > If you mean changes to Mode 6, I'm not sure enough that shipping both hex
> > and text would fix anything to we want to do it. How do we know old code
> > wouldn't barf on the following text? Naive implementations in scripting
> > languages would do that.
>
> If you look at the old code up a level from the detailed chunk that sends
> each field, you find that there is logic to scramble the order and send bogus
> extra fields. The intention was to make sure client code didn't do the
> simple things that would break when fields are added.
>
> So I think that old code will keep working as long as we keep sending the old
> fields without changing them. Or at least any somewhat sane code. I don't
> think we have to worry about the rest.
Ah, I think I misunderstood your proposal. You're suggesting adding *new*
response components that have unpacked strings in them. That makes sense.
I thought you were suggesting something else. I'll add this to the list
of potential work items I'm putting together.
> e...@thyrsus.com said:
> >> Do we need to start tracking what we will support and/or develop
> >> a policy for when we drop support for a slot?
>
> > I've been obsessive about documenting visible changes; see docs/ntpsec.txt
> > for them all. There have not been many such things, and only one change in
> > Mode 6. There's one context in which it ships a driver name rather than a
> > number now.
>
> What I was trying to suggest was a list of the fields and which ones came
> from ntp classic (call it version 0.0) and which ones we added and which
> version we added them in and which fields they replace and/or have been
> replaced by and/or some policy about how long we support each version.
>
> I'm assuming that we can add things to test them without a lot of discussion,
> but maybe we should think twice before we ship an actual released version
> that has them since that commits us to support for a long time.
docs/mode6.txt
See "Compatibility Notes". It's a start. anyway - no policy there.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
