Sane behaviour for servicetype="image"

In our Registry interface, we have had an "image" service type for a long time. It has so far been a synonym for sia1. Now that our Registry discovery supports sia2, too, the question is what to do with the image service type.

Here's a few options I have been pondering:

(1) Leave things as they are. Not pretty, because why should sia2 *not* be image?

(2) Deprecate servicetype="image" and then one day drop it. Well, we can always do that when we find out we can't come up with useful semantics.

(3) Make image the union of sia and sia2. I think that's about the worst we can do, because several services offer both sia and sia2, and these will then be queried twice (though we can't avoid duplicate results in general; in DaCHS services, for instance, there's just one global SIA2 service but many per-data collection SIA services, and it's hard to work out which SIA results you might also get through SIA2).

(4) Make image return sia services where available and sia2 otherwise. Since I personally don't like sia2 in its current state, I'd like that a lot. But we'd have quite a bit of explaining to do if we went for that.

(5) Make image return sia2 services where available and sia otherwise. I think that is about the least surprising thing we can do.

For (3) through (5), however, we have the additional problem of what get_service() would return. For reference, SIAService's search has the signature

```
(pos[, size, format, intersect, verbosity]) -> SIAResults
```

whereas SIA2Service's has

```
(pos=None, band=None, time=None, pol=None, field_of_view=None, spatial_resolution=None, spectral_resolving_power=None, exptime=None, timeres=None, publisher_did=None, facility=None, collection=None, instrument=None, data_type=None, calib_level=None, target_name=None, res_format=None, maxrec=None, session=None, **kwargs) -> SIA2Results
```

– where pos is, I think, a rather different beast in SIA2Service than in SIAService (it is in the protocol, I've not looked at the pyVO implementation).

This means that if we want to enable something like:

```
for svc in registry.search(servicetype="image"):
matches = svc.search(???)
for row in matches:
# do something interesting with row
```

I think we won't get around a compatibility shim. What could this be? We *could* implement SIA2's extra conditions as good as we can locally on top of SIAResults (with suffiently rich service responses, that would be reasonable for band, time, and serveral of the others; btw: you don't have any guarantees that the constraints will be honoured in SIA2 either). But, really, someone else would have to contribute code for that. Volunteers?

Me, I think I'd do a GenericImageService with a search that just has pos and size, which would be translated into a CIRCLE query against SIA2 services. The return rows, on the other hand, would be pretty much SIA2Results, which are basically obscore rows.

So, what does everyone think? Do you perhaps have better ideas? I predict our future selves will be grateful if we think about this a bit. We'll always have similar problems when we have two major versions of a protocol coexisting, and this will probably happen quite a few times in the VO's future.

Should we have a side meeting on this in Bologna?

Start with the Registry interface around registry.search(servicetype="image") and get_service(), then compare the SIAService.search and SIA2Service.search signatures described in the issue. Resolve the intended image semantics and compatibility-shim contract, including query arguments and the returned result type; done means an agreed, testable implementation path exists.

Written by the indexing model from the issue text.