Another GMS WD

[Markus Demleitner]

Hi Brian,

On Wed, Apr 03, 2019 at 10:34:27PM +0000, Mark Taylor wrote:
> a few comments on WD-GMS-1.0-20190329 as requested:
> 
> On changing the IVOID scheme from ivo to gms:
>    As I understand it, it's not an IVOID if it doesn't use the "ivo" scheme.
>    IVOID 2.0 section 2.3.1 says: "The <scheme> part of IVOIDs is ivo.".
> 
>    I think(?) that you should abandon the idea of syntactically signalling
>    that an IVOID is a Group Identifier.  It's not necessary to do that
>    anyway, that's properly signalled by context: an IVOID can be
>    treated as a Group Identifier if a capability of its resource has
>    standard_id="ivo://ivoa.net/std/gms#search-1.0" (er, or something
>    like that).
> 
>    Note that the examples in section 4.2 still use the ivo scheme
>    in any case - at least usage has to be consistent.

Yes, there shouldn't be any identifiers with a non-ivo scheme in the
Registry for now.  I'm not saying we can't ever have any of these,
but if they go in, we need a good plan and understand what that
means.

>From what I understand of what you're doing here, I don't think
there's a major reason to have that.  However, there *may* be a point
to introduce a new URL scheme outside of the registry.  As follows:

Essentially you're saying "to identify a group, use an identifier
like gms://<authority>/<path>?<group>"; incidentally, while skimming
the document I couldn't quite figure out where these group ids would
actually show up in operation (a securityMethod in an interface?
some sort of service response?).  Perhaps I've not read the document
well enough, but if there's really nothing about that, that kind of
information would help a lot, in particular for the TCG review that
needs to look at implementations.

Anyway: the RegTAP query indicates that what ivo://<authority>/<path>
points to is some sort of service with a capability with standardID
ivo://ivoa.net/std/gms#search-1.0.

Having been burned before, I'd first strongly advise to restrict the
structure of this resource record of that service, perhaps somewhat
like this:

  A GMS service is described by a resource of type vr:Service [or
  perhaps derive a custom resource type if you need additional
  metadata?] with at least one capability with standardID
  ivo://ivoa.net/std/gms#search-1.0.  In each such capability,
  exactly one interface must be declared as role="std"; this contains
  the access URL (and possibly mirror URLs) of the service described
  here.

  Informationally, in RegTAP 1.0, a query that resolves a GMS
  service's IVOID to the access URL usable without authorisation is:

    SELECT access_url
    FROM rr.interface
    NATURAL JOIN rr.capability
    NATURAL JOIN rr.resource
    WHERE
      ivoid = 'gms://authority.example.com/gms1' 
      AND standard_id = 'ivo://ivoa.net/std/gms#search-1.0'
      AND intf_role='std'
      AND security_method_id IS NULL

[this is shooting from the hip, so take it with a generous helping of
salt].

I'm saying "informationally", because we shouldn't link GMS to RegTAP if
we can avoid it (which I think we can).  It's a good idea to
show explicit usage patterns, though, so I heartily support including
the query people should use *for the time being*.  But if some new
standard for registry access appears, we shouldn't need to change
GMS.

In the query that's in the document now, you include
security_method_id.  If it is forseen that GMS services will have
complex authentication requirements, then we may need to change the
language about "exactly one interface" above to something like "at
least one interface must be declared as role="std", where for each
securityMethod there may only be one such interface" or so.
Obviously, if there's no such scenario I'm all for skipping that
complication.

>From there, the issue of the URI scheme becomes a bit cleaner to me.
Essentially, it's the question of "how to resolve the URI".  The
Identifier standard says something to the effect of "To resolve an
IVOID, cut off the query part, resolve the result, and if there was a
query part to begin with, do something depending on what sort of
identifier you have and the resource you get."  

For instance, if you know what you have is a PubDID, and the record
you get back has an SSAP capability, you'd to a PUBLISHERDID query to
that resource.

You *could* define that "A group id is resolved by using the GMS
capability with the query part by issuing a query as per section
4.1", and you'd be well within what Identifiers 2.0 lets you do.
That's actually what I'd recommend doing, as I suppose whereever the
group ids turn up it's clear they're group ids in the first place
(rather than, say, publisher DIDs).

If you forsee a major use case where clients have to figure out up
front whether an identifier is a group ID or something else, a gms:
scheme would indeed be the way to go.  Actually, researching what it
needs to legally claim a scheme identifier would be a worthwhile
thing to do because I think we never bothered to do that for our ivo
scheme, either.

These gms URIs should still not get into the registry, and the GMS
services should still have ivo URIs even in that case, though.  You'd
have to have language like

  To resolve a gms URI:
    
  (a) take the authority and path part, form an IVOID with them,
      and resolve that identifier in the registry to GMS service access
      URL.

  (b) take the query part of the GMS URI and issue a GET on the
      discovered service's search/{group} endpoint.

  For instance, gms://example.org/ingroup?punks would be resolved by
  querying the Registry for a GMS endpoint of
  ivo://example.org/ingroup and then retrieve <discovered
  URL>search/punks.

(where somewhere else you should probably say whether the access URL
must or must not end with a slash so the simple concatenation just
works).

Given that, if you don't have a strong use case for going the extra
schema route, my advice is to stay with ivo.

> Section 3.2 item 3:
>    The IVOID standard seems to use the term "resource key" rather 
>    than "path" for this part of the identifier (IVOID 2.0 section 2.3.3).
>    I can't remember if there's an important reason for that, but it
>    might be a good idea to follow the IVOID rather than URI terminology.

Well... I've never been much of a fan of that "resource key" language
myself and just took it over from Identifiers 1.0.  Let's say I'm
neutral on the terminology here -- you're in trouble with either URI
or Identifiers, so it's a bit of choosing one's poison.

My advice would be: if you use the gms schema, talk about path, if
you keep ivo, talk about resource keys.

Oh, and I've committed some minor typographical changes in rev. 5379.

Also, I notice you don't have the arch diagram yet.  If you tell me
what you'd like GMS to be related with, I'm happy to quickly make one
for you.

        -- Markus