URI/URL

Each UNIT is identified by a unique UNIT-URI that can be mapped unambiguously to a https UNIT-URL. Each UNIT-URI contains the email-address of it's PRODUCER. If the resp. email-provider supports UNITED-PAGES it is called the NATIVE-PROVIDER otherwise united-pages.com is called the DEFAULT-PROVIDER.

A UNIT-URI starts with the scheme "unit", followed by the abbreviation of its UNIT-CLASS(e.g. cal for calendar), the email-address of the PRODUCER and ends up with an optional query. As known from http-query-parameters the query is separated by ‘?’ and parameters are separated by ‘&’. The mapped UNIT-URL depends partially on the resp. UP-PROVIDER(native vs. default).

<unit-uri> ::= unit://<unit-class>/<local-part>@<domain-part>[?<query>]
<unit-url> ::= https://<up-domain-part>/<unit-class>/<local-part>/<domain-part>[?<query>]
<unit-class> ::= 'air' | 'cal' | 'cct' | 'dev' | 'dom' | 'doms ' | 'fle' | 'idy' | 'loc' |
                       'lst' | 'mail' | 'msg' | 'pky' | 'pwd' | 'ref' | 'sce' | 'tok'
<query> ::= <query_id>[&_black=<blacklist>]|[&_flag<flag>]
<flag> ::= 'all' | 'download' | 'plain'
<up-domain-part> ::= <native-domain-part> | 'www.united-pages.com/unit'
<blacklist> ::= <unit-variable> | <unit-variable>,<blacklist>
<query_id> ::= <identifier>=<value> | <identifier>=<value>&<query_id>

Semantic:

<native-domain-part> ~ result of GET https://www.united-pages.com/unit/dom/<domain-part>
e.g GET https://www.united-pages.com/unit/dom/goohoo.com -> { 

<local-part> ~ RFC5322 IMF (Internet Message Format)
<domain-part> ~ RFC5322 IMF (Internet Message Format)
<query> ~ RFC 3986 URI(Uniform Resource Identifier)
<blacklist> ~ every variable in blacklist is not part of a GET-response
<all> ~ all unit-uri of the resp. unit-class are listed in a GET-response
<download> ~ if download is set in GET request on a fle UNIT the resp. file is downloaded
<plain> ~ no inheritance is evaluated

How is a <unit-uri> mapped to <unit-url>?

(I) native

<unit-uri> unit://cct/john.doe@goohoo.com
<unit-url> https://api.goohoo.com/up/cct/john.doe/goohoo.com

(II) default

<unit-uri> unit://cal/praxis@medicus.de?q=123
<unit-url> https://www.united-pages.com/unit/cal/praxis/medicus.de?q=123

Small/capital letters and the sequence of http-query-parameters in a UP-URI are not decisive, e.g. the following URIs are semantically identical:

unit://cal/praxis@medicus.de?id=abc
unit://CAL/Praxis@Medicus.de?iD=ABc

How is the native-domain-part determined?

(I) GET-request of all native domain-mappings:

GET https://www.united-pages.com/unit/doms
-> e.g. {“up”:"(goohoo.com,api.goohoo.com/unit),(gmx.net,www.gmx.com/up),(gmx.de,www.gmx.com/up),(gmail.com,api.google.com/united ),...”}

(II) GET request for a concrete domain-part:

GET https://www.united-pages.com/unit/dom/<domain-part>
-> e.g. GET http://www.united-pages.com/unit/dom/goohoo.com returns {“up”:”api.goohoo.com/unit”}

Where is <unit-uri> used?

Instead of focusing only on <unit-url> for the following reasons the <unit-uri> format is specified additionally:
- the <unit-uri> does not need to consider whether a domain is supported by its native email-provider
- it is not a must to use http(s) for webservices (only state-of-the-art)
- <unit-uri> is shorter and more intuitive for humans
- a unique scheme (here: unit) can be coupled with a certain application, i.e. a certain App can be started when clicking on a certain <unit-uri> within Email or Messenger e.g.

Hello John Doe, 

your next appointment:

unit://cal/praxis@medicus.de?id=123

Regards
Your medicus team
unit://cct/praxis@medicus.de?q=dispatcher