Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allowing non-HTTP protocols #354

Open
vmx opened this issue Mar 20, 2020 · 0 comments
Open

Allowing non-HTTP protocols #354

vmx opened this issue Mar 20, 2020 · 0 comments
Labels
OGC API: Common Issue related to general resources or requirements (see #190) Part 1: Core Issue related to Part 1 - Core

Comments

@vmx
Copy link
Contributor

vmx commented Mar 20, 2020

The current OGC API - Features - Part 1: Core talks about HTTP as protocol. I'd like to suggest to allow other non-HTTP protocols as well.

Please not that I just want to make sure that things can be implemented on top of another protocol and still be spec compliant (hopefully). As HTTP currently is the major protocol for the Web, it is highly speculative if other protocols will be used widely anytime soon. Hence I also don't want to rewrite the whole spec into something which is protocol independent and hence hard to understand.

I want to start small, with just allowing non-HTTP URIs.

Background

I'm involved in content-addressed systems (as opposed to location-addressed sytems like the Web). I see many benefits in those, if you want to know more, I've given an introduction into content-addressed system in my FOSS4G talk "Geodata on IPFS" last year. I'm also happy going into more details about that during the discussions on that issue.

I've build a prototype of a STAC catalog based on top of a content addressed system (online demo. It is still using HTTP, but could potentially use other protocols.

The main difference here is that links are not using URIs starting with http:, but with ipld:. This is in accordance with the STAC spec, which allows an URIs.

Proposal

I'd like this standard to allow any URIs and not just HTTP based ones. Currently the section HTTP URIs states:

This document does not restrict the lexical space of URIs used in the API beyond the requirements of the HTTP and URI Syntax IETF RFCs. If URIs include reserved characters that are delimiters in the URI subcomponent, these have to be percent-encoded.

Could this perhaps be made less strict into something like (the exact wording surely is open for discussion, I just want you to give an idea what I've after).

This document does not restrict the lexical space of URIs used in the API beyond the requirements of the URI Syntax IETF RFCs. If HTTP URIs are used and include reserved characters that are delimiters in the URI subcomponent, these have to be percent-encoded.

@cportele cportele added this to Backlog in Part 1: Core via automation Mar 30, 2020
@cportele cportele added OGC API: Common Issue related to general resources or requirements (see #190) Part 1: Core Issue related to Part 1 - Core labels Mar 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
OGC API: Common Issue related to general resources or requirements (see #190) Part 1: Core Issue related to Part 1 - Core
Projects
Part 1: Core
  
Backlog
Development

No branches or pull requests

2 participants