Registry Interfaces 1.1: WG comments?

[Norman Gray]

Markus and Theresa, hello.

On 31 Aug 2015, at 9:16, Markus Demleitner wrote:

> Howwever, the actual URL,
>
> http://rofr.ivoa.net/cgi-bin/oai.pl
>
> IMHO is not ideal, as it communicates two technology choices -- CCI
> and Perl -- that may change and even today smell a bit stuffy to
> several noses.  I'd much rather have a generic URI that would be
> mapped by ScriptAliases or whatever URI mapping mechanisms future
> servers have.  I'd propose
>
> http://rofr.ivoa.net/oai

There is broad precedent for this in RFC 5785 
<http://www.ietf.org/rfc/rfc5785.txt>, which discusses the registration 
of 'well-known URIs'.  From the introduction to that:

> It is increasingly common for Web-based protocols to require the
>  discovery of policy or other information about a host ("site-wide
>  metadata") before making a request.  For example, the Robots
>  Exclusion Protocol <http://www.robotstxt.org/> specifies a way for
>  automated processes to obtain permission to access resources;
>  likewise, the Platform for Privacy Preferences [W3C.REC-P3P-20020416]
>  tells user-agents how to discover privacy policy beforehand.
>
>  While there are several ways to access per-resource metadata (e.g.,
>  HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead
>  (either in terms of client-perceived latency and/or deployment
>  difficulties) associated with them often precludes their use in these
>  scenarios.
>
>  When this happens, it is common to designate a "well-known location"
>  for such data, so that it can be easily located.
> [...]
>
>  There are a number of possible ways that applications could use Well-
>  known URIs.  However, in keeping with the Architecture of the World-
>  Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended
>  for general information retrieval or establishment of large URI
>  namespaces on the Web.  Rather, they are designed to facilitate
>  discovery of information on a site when it isn't practical to use
>  other mechanisms; for example, when discovering policy that needs to
>  be evaluated before a resource is accessed, or when using multiple
>  round-trips is judged detrimental to performance.

I think this would give sample rationale for something like 
rofr.ivoa.net/oai (or something similar).

A side-point re Markus's postscript:

> [1] Incidentally, at the GAVO data center, we're using oai.xml rather
> than oai, as that gives a useful extension to the document when
> saving from popular clients like curl.  I'm not sure if I'd like to
> propose this fake extension as a central IVOA policy.

Another way to manage this is to have .../oai redirect (in the 3xx 
sense) to .../oai.xml if there's an appropriate Accept header in the 
request.  Or .../oai.foo, or whatever.  That doesn't help with the 
on-disk file extension, but it helps when being agnostic about what 
syntax is to come back from the server.  ConNeg isn't just for REST, you 
know.

All the best,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK