[noise] Document structure (was: Mechanical definition of "fallback" modifier)

[Alex]

On Sun, 11 Jun 2017 07:08:19 +0000
Trevor Perrin <trevp at trevp.net> wrote:

> On Sun, Jun 11, 2017 at 1:56 AM, Rhys Weatherley
> <rhys.weatherley at gmail.com> wrote:
> >
> > Should the definition of the "fallback" modifier go into rev33 or
> > into an extension document?  Perhaps Noise Pipes can be spun off
> > completely into an extension now?  An important extension to be
> > sure, but maybe no longer necessary in the core.  
> 
> 
> Not sure.  I talked about that with Jason before revision 32 and he
> convinced me this is complicated and needs more discussion:
> 
>  * If we're going to divide things into separate documents (or
> "chapters", or "layers"), what is the division based on?  Old vs new?
> More-important vs less-important?  Modifiers vs non-modifiers?
> 

What is the very least a library author should have to do to consider
their implementation compliant? If an author decides not to implement
PSKs, are they violating the standard? If not, maybe section 9 should
be in a separate document.

Similarly it seems that fallback patterns (section 10) are completely
optional *and* the spec only makes a recommendation for how to
implement it. Additionally, the type fields in fallback patterns are
explicitly designated as application responsibilities in section 13.
This seems like a good candidate for something that can be moved in to
another document.

>  * Are these decisions we're able to make now?
> 

I think so.

> It would be great to hear thoughts about how these decisions would
> affect people, e.g. would having separate documents make things easier
> for library developers to focus on features they care about, or create
> confusion and fragmentation?
> 

My biggest concern is that compliance is well defined. I want it to be
completely unambiguous as to whether you are in or out of compliance.
I suspect that a minimalist core spec with supporting documents for
non-normative recommendations would make this challenge more tractable.

-- 
Alex