improvement: extend the "format" request parameter to explicitly allow specifying miniseed3 response

[kaestli]

Up to now, the optional "format=miniseed" request parameter was kind of a placeholder, as the standard did not provide any options, and the only de-facto response format was miniseed v.2.
With the adoption of miniseed v.3 as an FDSN standard a year ago, this clarity risks to be gone, as "miniseed" could be either miniseed2 or miniseed3.
I'd suggest to specify, as a part of the next minor update of the service specification to 1.2:

• format=miniseed => response is in miniseed v.2
• format=miniseed3 => response is in miniseed v.3
• (default = miniseed)
  Thus, the behaviour of the service, from the point of view of the client, would remain fully backwards compatible with the service version 1.1
  It would be left to the service implementation whether data is only shipped as far as the requested format is the same as the format available in the archive, or whether the service offers on-the-fly conversion.
  (obviously, a mixed content response file is not possible, as it would neither fulfill the miniseed v.2 nor the miniseed v.3 specification.)

[crotwell]

Could also add another format value for original, so format not modified by the datacenter. But has the downside of returning mixed content, which could be problematic for some clients.

Also worth clarifying what happens if the requested format is not the format stored and the data center can't or won't convert it. Miniseed2->3 should always be convertible in principle, but miniseed3 may not be convertible to 2, for example longer station and channel codes. Should server just not return, or attempt to notify via error.

Perhaps some custom http headers could be used in some way to transmit whether there was any data not returned due to conversion issues?

[chad-earthscope]

Summary of discussion at the Lisbon 2025 meeting of WG 3:

If miniseed is specified (or assumed as the default) it means miniseed (v2), that forces conversion of future data from v3 to v2 - this can be very inefficient with unfilled v2 records, and can be a lossy conversion, some things in v3 cannot be converted to v2, or as @crotwell writes above have codes longer than supported by v2. On the other hand, the conversion of v2 miniSEED to v3 is (nearly) lossless and relatively easy; [Chad's] suggestion for clients of the future that cannot handle mixed-version miniSEED would be to request v3 for this reason.

To avoid the creation of inefficient or impossible conversion (due to longer identifier codes) in v2 when converted from v3, if the service omits data in v3 when format=miniseed users will not easily know that data has been omitted.

On the other hand if we interpret the default value of format (miniseed) to mean the "native" format version, the user may receive a version of the format they cannot read and will be prompted to find tools to read it. There was agreement that this was better than omitting data.