From msdemlei at ari.uni-heidelberg.de  Wed Aug  5 08:26:10 2026
From: msdemlei at ari.uni-heidelberg.de (Markus Demleitner)
Date: Wed, 5 Aug 2026 08:26:10 +0200
Subject: SCS2 Migration Plan
In-Reply-To: <CAPx=0xNJWwaky2Y9cZLGcM5w-3CXTtGNmzpLEwhBif55vPA-BA@mail.gmail.com>
References: <o5np2ducamunktj4pefh7rt6qs444yndqwrwckvksd46nqvwxf@7pvfrtd5vphu>
 <CAPx=0xNJWwaky2Y9cZLGcM5w-3CXTtGNmzpLEwhBif55vPA-BA@mail.gmail.com>
Message-ID: <cwigd6srmf73uginjspepugdmf6bv2xjqoa7ayxo4x5air2vzc@xxh46xghun6a>

Hi DAL,

On Tue, Aug 04, 2026 at 11:02:03AM -0700, Stelios Voutsinas wrote:
> One more question to iron out the details I have is whether it is valid for
> a service to co-locate both dialects under the same accessURL?
> If this is allowed, there might be some confusion due to the different
> error conventions, but I don't know how common a use case that would be or
> if the spec should take a position one way or another.

I have not thought this through.  Ages ago, it was thought that by
passing in a VERSION parameter, such a co-location would be simple
and safe.  We have shelved that idea for many reasons, and I believe
plannig for it is asking for all kinds of trouble, in particular
raising the expectation that multiple versions live next to each
other beyond a (notionally brief) transition time.

My stance would be: If you think you can reliably auto-detect the
protocol version, I'd not come after you.  But I'd neither design
protocols such that that is easy nor would I discuss such a design in
the spec.

URLs are cheap.  Guessing is hard.  I'd use two URIs.

Thanks,

          Markus


From msdemlei at ari.uni-heidelberg.de  Wed Aug  5 09:54:22 2026
From: msdemlei at ari.uni-heidelberg.de (Markus Demleitner)
Date: Wed, 5 Aug 2026 09:54:22 +0200
Subject: SCS2 Migration Plan
In-Reply-To: <CAPx=0xNJWwaky2Y9cZLGcM5w-3CXTtGNmzpLEwhBif55vPA-BA@mail.gmail.com>
References: <o5np2ducamunktj4pefh7rt6qs444yndqwrwckvksd46nqvwxf@7pvfrtd5vphu>
 <CAPx=0xNJWwaky2Y9cZLGcM5w-3CXTtGNmzpLEwhBif55vPA-BA@mail.gmail.com>
Message-ID: <mh6rbnb6ppae2zxlclmxessk2gj5wwgrcrj4egicuhlryhgdkz@7urfhkzqjhua>

Dear DAL,

On Tue, Aug 04, 2026 at 11:02:03AM -0700, Stelios Voutsinas wrote:
> "Operators currently running a ConeSearch-1 service SHOULD NOT retire it
> before the transition team declares the migration window closed. New
> implementations of SCS2 MAY do so without also standing up a ConeSearch-1
> interface."

What do you think of <https://github.com/ivoa-std/SCS2/pull/6>?  I've
made this a little less standardese because the appendix is
non-normative anyway.

Thanks,

        Markus


From stelios.voutsinas at noirlab.edu  Tue Aug  4 20:02:03 2026
From: stelios.voutsinas at noirlab.edu (Stelios Voutsinas)
Date: Tue, 4 Aug 2026 11:02:03 -0700
Subject: SCS2 Migration Plan
In-Reply-To: <o5np2ducamunktj4pefh7rt6qs444yndqwrwckvksd46nqvwxf@7pvfrtd5vphu>
References: <o5np2ducamunktj4pefh7rt6qs444yndqwrwckvksd46nqvwxf@7pvfrtd5vphu>
Message-ID: <CAPx=0xNJWwaky2Y9cZLGcM5w-3CXTtGNmzpLEwhBif55vPA-BA@mail.gmail.com>

Thanks Markus for raising this as well as the pointer to the Gavo record,
that does resolve my question on #3.
One more question to iron out the details I have is whether it is valid for
a service to co-locate both dialects under the same accessURL?
If this is allowed, there might be some confusion due to the different
error conventions, but I don't know how common a use case that would be or
if the spec should take a position one way or another.

On #7 I think your minimal language works for me and fixes my objection,
that new implementors shouldn't have to stand up a legacy interface they
have no other reason to build.
Perhaps to make it even more explicit:

"Operators currently running a ConeSearch-1 service SHOULD NOT retire it
before the transition team declares the migration window closed. New
implementations of SCS2 MAY do so without also standing up a ConeSearch-1
interface."

Thanks,

Stelios

On Mon, Jul 27, 2026 at 5:39?AM Markus Demleitner via dal <dal at ivoa.net>
wrote:

> Dear DAL folks,
>
> In my loose series of community polling on Stelios' comments on
> SCS2[1], I'd say the last question (Jul 9th) on POST support is
> settled in DALI 1.2.  So, let's move on to:
>
>   7. Migration plan
>
>   I think it's less than ideal and an unnecessary hurdle to have to
>   require all SCS2 services (including new service creators) to be
>   accompanied by ConeSearch-1.0 interfaces.
>   Also, I don't know if it is clear how registry records should be
>   structured for a service that implements both 1.1 and 2.0
>   simultaneously (One record or two? Should VOSI capabilities list
>   both capability types?)
>   I'd be in favor of exempting new SCS2 ConeSearch implementors of
>   having to write implementations for both.
>
> On the requirement of parallel implementations... well, this is a
> consequence of the original desideratum "No VO splits" from the
> College Park talk
> <https://wiki.ivoa.net/internal/IVOA/InterOpJune2025MVT/lecture-notes.pdf
> >.
>
> Something's got to give, sure, and perhaps it's acceptable if legacy
> clients don't see the most recent services.  I *would* like to say
> that until we offcially pull ConeSearch-1, the differences should be
> as small as possible.  I'd say the minimal language should be "If you
> already run a ConeSearch-1 service, don't pull it until the
> transition team tells you to."  I am very grateful for suggestions
> what to write.
>
> The Registry records... well, at least for legacy services they stay
> as they are, including their granularity, except there will be an
> extra capability with the SCS2 standardID.  That means that sure, as
> long as it's there, the VOSI capabilities will have both ConeSearch-1
> and SCS2 capabilities.  The PoC record:
>
>
> http://dc.g-vo.org/oai.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://org.gavo.dc/gaia/q3/cone
>
> shows how it's supposed to look like (or at least I hope so:-).
>
> Thanks,
>
>            Markus
>
>
> [1] https://github.com/msdemlei/scs2-original-deleteme/issues/2
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20260804/a173816c/attachment.htm>

From marco.molinaro at inaf.it  Wed Aug  5 16:29:06 2026
From: marco.molinaro at inaf.it (Molinaro, Marco)
Date: Wed, 5 Aug 2026 16:29:06 +0200
Subject: WD ConeSearch 1.1 - for "final" group review
Message-ID: <CAFtRUxLFCzC4JSH4dBv5Tswi6u4K9XBJNVYULZP09no_r2cUmw@mail.gmail.com>

Dear DAL,

to move forward with ConeSearch-1.1, please find
attached here a working draft that is meant to
collect final feedback and review within the group
on the updated specification (that covers all the
1.1 marked issue on github).

While feedback comes in (on this list, on the github
repo https://github.com/ivoa-std/ConeSearch, on the
slack DAL channel, ...) the next planned steps are
for the OpenAPI document to add to the specification,
and for implementations and validator suite(s).

Thank you for your attention,
    Marco

-- 
Marco Molinaro
INAF - Istituto Nazionale di AstroFisica
Osservatorio Astronomico di Trieste
email marco.molinaro at inaf.it
tel. [+39] 333 33 20 564 [also Telegram]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20260805/346427c7/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WD-ConeSearch-1.1-20260609.pdf
Type: application/pdf
Size: 412456 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20260805/346427c7/attachment-0001.pdf>