Propose to clarify two ambiguities in the current specifications.

[kaestli]

1. Requirement (?) of supporting aliases for mandatory request parameters
   The pecification says that parameters such as “network”, "station" etc. are parameters for which the support is mandatory. There are aliases defined for both mandatory and optional parameters. However, aliases are not mentioned in the minimum functionality section of page 3 of the Commonalities. Thestatement on Aliases is (e.g. p. 2 of the station specification): “The alias values are acceptable synonyms for the given parameter name.” At least for me, it is not clear whether this makes an alias inheriting the support requirement of the corresponding parameter, or whether supporting the alias is optional and should be declared in the wadl, as for optional parameters.

2. Treatment of optional parameters:
   The specification of the services (e.g. FDSN/station, page 2) say: “The service shall accept requests formulated using the parameters identified in Table 1” (with table 1 containing both the required and the optional parameters). It is not clear (to me) whether this requests the service

• either, to accept all those parameters (without error code), while having the option to not implement them (thus, execute the request with http 200 by just assuming default behavior for the unsupported parameter, irrespectively of the actual parameter value)
• or, to indicate a unsupported table 1 parameter with error 400 (“Bad request due to improper specification, unrecognized parameter, parameter value out of range, etc.”), and the failure of the request (which seems consistent with the definition of http 400, but, in fact, would mean not accepting it.)

Note that for both ambiguities, there are existing fdsnws implementations showing either of the behaviours. Therefore, I'd like to suggest a clarification of these points in future versions of the standard.