On 31-Aug-22 14:11, Larry Masinter wrote:
TL;DR proposal: register drop# as requested (with a note added); then maybe we can drop#it.
Even your reference [7], which appears pretty quixotic, says: url ::= [ scheme : ] ( auth-path | path ) [ ? query ] [ # fragment ] See that mandatory ":" there? Brian
A "URI scheme" is kind of like a domain name from the following perspective: If you own the top-level domain "pizza" then you have the right to hand out names like "joes.pizza" and "best.pizza" and "tasty.pizza". These domain names are valuable and you have to pay big bucks to be able to own that right. Not too long ago there was a big flap over the sale of ".org" to a private equity group for an ungodly amount. From the point of view of imagining how most people in the world think about these things, "http" and ".org" are "drop" (in drop#something) are kind of the same kind of thing. Now, if you own a URI (or if you like, URL) scheme, like "pizza" (or "drop") you might think this gives you the right to hand or manage or control names starting with those, like "pizza:joes or pizza:best", or "drop:everything" or "drop:number" or "drop:dead". That is, the resource identified was the abstraction, with representations of abstractions imply an implicit MIME type with fragment identifiers naming the actual concept identified. You might even establish a convention that the "drop" URI scheme supports a null body so that "drop:" by itself identified "the world of drop numbers" and the particular semantics of "the world of drop numbers" was instead typically identified by the fragment identifier, so that "drop:#best%20pizza" would turn out to identify the source of the best pizza (at least as designated by the owner of the "drop" scheme). You might even want to build and deploy a set of clients and utilities that had the convention that a URI without a host or path but with a fragment identifier could be transmitted and understood that the intervening punctuation can be elided, allowing usages such as "drop#pizza", "drop#everything" or even "drop#dead". You might even plan to offer a service (as RealNames and others [1] did) using the Common Name Resolution Protocol [2] (or an alternative meeting the same goals [3]). Perhaps you could use an existing registered but unused scheme (e.g. "go" [4]) or register a new one (say "drop"). The syntax of URIs / URLs is not settled; the IETF has RFC 3986[5], WHATWG has the URL Living Standard[6], with mare more candidates for a definitive specification [7] (message received TODAY!).. Pleas to address the situation [8][9] or even consistent implementation in browsers have largely gone unheeded [10]. But the one thing that is worse than having two incompatible specs for the "same" thing (if they are) is having three. URI/URL scheme registration procedures and guidelines have changed over time, mainly ignoring the reality that there is little impact in this world in having your scheme registered. What matters is what you can get implementors to implement or delegate if you have the right apps installed on your phone or pad or desktop. There are tons of unimplemented schemes in the IANA registry[11] and tons of implemented schemes with no registration. Wikipedia[12] is a better source. Meanwhile, through BCP 35 RFC 4395, RFC 6085, RFC 8615, RFC 7595 and others, we've spent a lot of thought on guidelines and processes that don't seem to matter.. In retrospect, the differences between "in use" and "registered" weren't due to problems addressed. Provisional registrations based on theory without practice are relatively harmless. If you register schemes such as RFC 2324 (which defined the scheme for "%E3%82%B3%E3%83%BC%E3%83%92%E3%83%BC") the internet doesn't care -- perhaps in future we might use ☕ 😋:. [1] https://datatracker.ietf.org/group/cnrp/ [2] https://datatracker.ietf.org/doc/rfc3367/ [3] https://datatracker.ietf.org/doc/rfc2972/ [4] https://datatracker.ietf.org/doc/rfc3368 [5] https://datatracker.ietf.org/doc/rfc3986 [6] https://url.spec.whatwg.org/ [7] https://github.com/whatwg/url/issues/479#issuecomment-1231491543 [8] https://daniel.haxx.se/blog/2017/01/30/one-url-standard-please/ [9] https://datatracker.ietf.org/doc/html/draft-ruby-url-problem-01 [10] https://twitter.com/samruby/status/1547646895027146753 [11] https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml [12] https://en.wikipedia.org/wiki/List_of_URI_schemes -- https://LarryMasinter.net https://interlisp.org
