[OAI-implementers] Should OAI-PMH over HTTPS be permitted?

[Patrick Hochstenbach]

A related issue: if Static Repository Files would also be accessible via
HTTPS, then constructing a OAI-PMH Gateway would be problematic because
gateways URL's don't contain the scheme of the original file location. 
E.g.

                                   ,-HTTP-OR-HTTPS-?-. 
http://www.gateway.org/somescript/www.university.edu/sr_file.xml?verb=Identify

I don't know if other types of gateways have the same problems.

Patrick Hochstenbach

On Thu, 17 Feb 2005, Thomas G. Habing wrote:

> Hussein Suleman wrote:
>>  > Which harvesters could not easily support HTTPS?
>> 
>> mine :) anything i distribute is meant to be as "dependency-free" as 
>> possible. historically, LWP has not been the easiest module to get working 
>> on a variety of architectures, so i don't use it.
>> 
>> if we require every harvester to support HTTPS, this will become the first 
>> feature that programmers will need to support through external code 
>> libraries. as such we will raise the "low barrier to entry" substantially.
>> 
>> i agree we should explicitly support HTTPS, but not require it.
>
> Because of the underlying APIs that we use (WinHTTP and MSXML), the harvester 
> that we use at UIUC supports HTTPS.  I agree with Hussein that harvesters 
> should be explicitly encouraged to support HTTPS, but it should not be a 
> requirement of the protocol.
>
> Maybe some advice on this topic could be added to the "Implementation 
> Guidelines" documents.
>
> Kind regards,
> 	Tom Habing
>
>> 
>> ttfn,
>> ----hussein
>> 
>> 
>> Simeon Warner wrote:
>> 
>>> There has been some interest recently in using OAI-PMH over HTTPS [1]. The
>>> OAI-PMH specification [2] mentions only operation over HTTP, so I think
>>> that at present HTTP must be used to conform to the specification (and
>>> this is enforced by the validation/registration site). The specification
>>> should be explicit about whether the use of HTTPS is conforming or not.
>>> 
>>> It would be trivial to extend the specification to permit the use of HTTPS
>>> as it is just standard HTTP operating over an additional security layer.
>>> There would be no need to change the semantics or syntax beyond the
>>> substitution of 'https://' for 'http://'. Permitting HTTPS would have no
>>> implications for data-providers unless they wished to use the protocol.
>>> The main implication of permitting HTTPS would be that harvesters would
>>> have to support HTTPS in addition to HTTP (or else be unable to harvest
>>> from some data-providers). In many programming environments there are
>>> libraries that provide seamless support for both HTTPS and HTTP (e.g. in
>>> Perl, HTTPS comes for free in LWP) but this may not be true in all cases.
>>> 
>>> Who is using or would like to use HTTPS?
>>> 
>>> Which harvesters already support HTTPS or could easily do so?
>>> 
>>> Which harvesters could not easily support HTTPS?
>>> 
>>> Cheers,
>>> Simeon
>>> 
>>> 
>>> [1] http://www.isi.edu/in-notes/rfc2818.txt
>>> [2] 
>>> http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm#HTTPembedding 
>>> 
>>> ----------------------------------------------------------
>>> Simeon Warner                 Email: simeon at cs.cornell.edu
>>> Cornell Information Science              Tel: 607-254-8605
>>> 301 College Ave                          Fax: 607-255-5196
>>> Ithaca, NY 14850-4623, USA
>>> 
>>> 
>>> _______________________________________________
>>> OAI-implementers mailing list
>>> List information, archives, preferences and to unsubscribe:
>>> http://www.openarchives.org/mailman/listinfo/oai-implementers
>>> 
>> 
>
>