Refine the relationship/differences between inputs vs parameters for operations

[tplooker]

Currently for each operation documented in the spec we have the notion of both inputs and parameters, a convention adopted from the bls-signature-draft.

Loosely what I think we have been following as a largely unwritten rule is that inputs are usually more dynamic or application driven/supplied in nature, where as parameters are more constant across multiple invocations of an operation(s).

To make things more complex we also appear to have two types/scopes of parameters, parameters shared across all operations vs parameters semi-unique to an operation, although it doesn't look like we are following this strictly.

I think we need to

1. Rationalise the difference between what constitutes an input vs a parameter
2. Decide on the scoping of various parameters and how we notate them in reference to specific operations for example do we inline them all? or reference them from a common section that applies to all operations, or both?

Furthermore I think we need to revisit certain values that may instead be considered parameters instead of inputs, in particular message generators. This is discussed more in #117

[BasileiosKal]

One option would be to define that anything that is described by a ciphersuite (i.e., base points etc.,) is a parameter. This will also apply to the message generators.

A stricter definition will be to consider anything that is defined by a ciphersuite AND it is independent from any inputs to be a parameter. This doesn't really apply to the message generators (their number depends to the number of messages).

Regarding 2 my vote is to inline the parameters if we would to consider the message generators as a parameter. If the message generators are supplied as input we can have a separate section to avoid repeated text.

[tplooker]

DIscussed on WG call 15th August, I will look through the spec to see if we have resolved the ambiguity that was previously present

[BasileiosKal]

Discussed on the WG on the 6th of February. Will check for any inconsistency and try to close next weak.

[BasileiosKal]

Discussed on WG on the 6th of Mar. Will check for consistency and close before publishing draft 02.

[tplooker]

Checks were done prior to draft-2 publication, no issue found, closing as a result.