BACKGROUND
Back in mid-2020, Solderpunk outlined the draft of a minimal subset of
Gemini, named Mercury:
https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpunk/gem
log/the-mercury-protocol.gmi
<https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpunk/ge
mlog/the-mercury-protocol.gmi>
That subset was always good enough for my needs, and that's what I have
been using since ? instead of Gemini proper.
What follows is my implementation highlights of Mercury ? for the record.
SERVICE DISCOVERY
mercury:// IRIs SHOULD be resolved through DNS service discovery:
# dig +short TXT _mercury._tcp.host.xyz.
multiaddr=/dns/host.xyz/tcp/1958/tls/sni/host.xyz
multiaddr ?
User-agents MUST support tcp.
User-agents MAY support tls.
Default multiaddr /dns4/host.xyz/tcp/1958
REQUEST 4,096 bytes UTF-8 IRI line
mercury://host.xyz/
RESPONSE 4,096 bytes UTF-8 status line
20 text/mercury;charset=utf-8;
Hello Mercury! ??
=> mercury://host.xyz/license CC0-1.0
<end of connection>
STATUS
2 digits code, 4,096 bytes UTF-8
2x (SUCCESS) 4,096 bytes UTF-8 content-type status line
20[ text/mercury;charset=utf-8;]
3x (REDIRECT) 4,096 bytes UTF-8 IRI status line
30 mercury://host.xyz/
4x (FAILURE) 4,096 bytes UTF-8 status line
40[ DESCRIPTION]
TEXT/MERCURY
text/mercury;charset=utf-8;
Text lines
Any line which is not a link.
Link lines
=> IRI[ DESCRIPTION]
=> mercury://host.xyz/license CC0-1.0
MERCURI URN
urn:mercury:capa
CAPA REQUEST
urn:mercury:capa
CAPA RESPONSE
20 text/mercury;charset=utf-8;
=> urn:mercury:capa
<end of connection>
Servers MUST support urn:mercury:capa.
MINIMAL SERVER
# while true; do { echo -e '20\r\n=> urn:mercury:capa'; } | nc -l 127.0.0.1 1958; done
MINIMAL CLIENT
# echo -e 'urn:mercury:capa\r\n' | nc 127.0.0.1 1958
20
=> urn:mercury:capa
That's all folks.
?0?
? https://github.com/multiformats/multiaddr <https://github.com/multiformats/multiaddr>
Any reason why port 1958 is chosen? I was thinking if it's adjacent to Gemini (minus TLS) then why not something like 1964? Not unlike XMPP's use of 5222 and 5223. I imagine *some* currently existing Gemini servers could benefit from serving Mercury alongside it just because they may not need encryption and it would be faster. (Although, I don't know how much TLS slows down the connection process, but on my system Gemini pages seem to take a while to open.) You say you have implemented Mercury. Does that mean you have a working client and server? Ben -- gemini://kwiecien.us/
On Sun, Feb 28, 2021 at 3:40 PM Petite Abeille <petite.abeille at gmail.com> wrote: > > That subset was always good enough for my needs, and that's what I have been using since ? instead of Gemini proper. +1 > What follows is my implementation highlights of Mercury ? for the record. (...) > REQUEST 4,096 bytes UTF-8 IRI line Yes. Bumping the request max size may allow e.g. very simple update schemes. I think this could also apply to the gemini protocol => https://lists.orbitalfox.eu/archives/gemini/2020/002045.html > MERCURI URN > urn:mercury:capa > > CAPA REQUEST > urn:mercury:capa > > CAPA RESPONSE > 20 text/mercury;charset=utf-8; > => urn:mercury:capa > <end of connection> > > Servers MUST support urn:mercury:capa. Why this specific requirement? I didn't find any reference to "urn:*:capa". What does it mean and what would be the returned values? Phil
On Sunday, February 28, 2021 8:23 PM, Ben <benulo at systemli.org> wrote: > Any reason why port 1958 is chosen? I was thinking if it's adjacent to > Gemini (minus TLS) then why not something like 1964? Not unlike XMPP's > use of 5222 and 5223. # NASA Project Gemini Duration: 1961?1966 First crewed flight: 1965 https://en.wikipedia.org/wiki/Project_Gemini # NASA Project Mercury Duration: 1958?1963 First crewed flight: 1961 https://en.wikipedia.org/wiki/Project_Mercury This is where the port numbers come from. Maybe 1961 would have been a better choice? -- Katarina
On 2021-02-28 10:53PM, Ben wrote: > Any reason why port 1958 is chosen? I was thinking if it's adjacent to > Gemini (minus TLS) then why not something like 1964? Not unlike XMPP's use > of 5222 and 5223. The same reason Gemini uses 1965: Project Mercury was created in 1958. https://en.wikipedia.org/wiki/Project_Mercury As for the rest of it, I belive it's kind of silly. Solderpunk didn't come up with Mercury as some sort of alternative where they're giving up on Gemini, they posed it as a hypothetical point of comparison between a very simple protocol like Mercury and something more complex like Gemini. It was never meant to be taken as serious new protocol proposal, they use it as a marker for another possible position on the "complexity axis" between Gopher and the web. Gemini is one point on that "axis," Mercury is another possible point, used as a reference beacon to help keep Gemini in-scope. ~nytpu -- Alex // nytpu alex at nytpu.com GPG Key: https://www.nytpu.com/files/pubkey.asc Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B https://useplaintext.email/
On 2/28/2021 11:23 AM, Ben wrote: > Any reason why port 1958 is chosen? I was thinking if it's adjacent to > Gemini (minus TLS) then why not something like 1964? Not unlike XMPP's > use of 5222 and 5223. Project Mercury ran from 1958 - 1963. Gemini uses port 1965 based on this same homage to the manned space programs leading up the the Apollo moon landing. More info on that here: https://en.wikipedia.org/wiki/Project_Mercury And since we're talking port numbers, that brings up another matter. Stephanie posted (or maybe I just read it on her page?) about a collision w/Tivoli on TCP 1965. She referred to it as a 'serious' conflict. No offense, but I don't see that as an issue at all. It's a non-privileged port and there are several instances where different types of services use the same ports with respect to UDP or TCP (even in /etc/services). I checked /etc/services on Debian Bullseye and Slackware -current just now and don't see port 1965 or Tivoli even mentioned. NOTE: This is not to say that it's not relevant or perhaps important to address, as Stephanie suggests. Here's something pertinent to that, as well as user accessibility: ```: A shitload of gobbledygook (noise) that prolly nobody wants to hear # From ``Assigned Numbers'': # #> The Registered Ports are not controlled by the IANA and on most systems #> can be used by ordinary user processes or programs executed by ordinary #> users. # #> Ports are used in the TCP [45,106] to name the ends of logical #> connections which carry long term conversations. For the purpose of #> providing services to unknown callers, a service contact port is #> defined. This list specifies the port used by the server process as its #> contact port. While the IANA can not control uses of these ports it #> does register or list uses of these ports as a convienence to the #> community. # socks 1080/tcp # socks proxy server socks 1080/udp proofd 1093/tcp proofd 1093/udp rootd 1094/tcp rootd 1094/udp openvpn 1194/tcp openvpn 1194/udp rmiregistry 1099/tcp # Java RMI Registry rmiregistry 1099/udp kazaa 1214/tcp kazaa 1214/udp nessus 1241/tcp # Nessus vulnerability nessus 1241/udp # assessment scanner lotusnote 1352/tcp lotusnotes # Lotus Note lotusnote 1352/udp lotusnotes ms-sql-s 1433/tcp # Microsoft SQL Server ms-sql-s 1433/udp ms-sql-m 1434/tcp # Microsoft SQL Monitor ms-sql-m 1434/udp ingreslock 1524/tcp ingreslock 1524/udp datametrics 1645/tcp old-radius datametrics 1645/udp old-radius sa-msg-port 1646/tcp old-radacct sa-msg-port 1646/udp old-radacct kermit 1649/tcp groupwise 1677/tcp groupwise 1677/udp l2f 1701/tcp l2tp l2f 1701/udp l2tp radius 1812/tcp radius 1812/udp radius-acct 1813/tcp radacct # Radius Accounting radius-acct 1813/udp radacct msnp 1863/tcp # MSN Messenger msnp 1863/udp unix-status 1957/tcp # remstats unix-status server log-server 1958/tcp # remstats log server remoteping 1959/tcp # remstats remoteping server cisco-sccp 2000/tcp # Cisco SCCP cisco-sccp 2000/udp search 2010/tcp ndtp pipe-server 2010/tcp pipe_server nfs 2049/tcp # Network File System nfs 2049/udp # Network File System gnunet 2086/tcp gnunet 2086/udp rtcm-sc104 2101/tcp # RTCM SC-104 IANA 1/29/99 rtcm-sc104 2101/udp gsigatekeeper 2119/tcp gsigatekeeper 2119/udp gris 2135/tcp # Grid Resource Information Server gris 2135/udp cvspserver 2401/tcp # CVS client/server operations cvspserver 2401/udp venus 2430/tcp # codacon port venus 2430/udp # Venus callback/wbc interface venus-se 2431/tcp # tcp side effects venus-se 2431/udp # udp sftp side effect codasrv 2432/tcp # not used codasrv 2432/udp # server port codasrv-se 2433/tcp # tcp side effects codasrv-se 2433/udp # udp sftp side effect mon 2583/tcp # MON traps mon 2583/udp dict 2628/tcp # Dictionary server dict 2628/udp ``` I dunno about anyone else here, but if I was blind, I sure as hell wouldn't want to listen to all of that. And as I pointed out in my immediately previous post, this isn't ASCII-art either. Remember folks, at this very moment in Gemini space, there are AT LEAST 113,310 pages of content, and that growth is logarithmic ;) I hope that helps :) Kindest regards, -- Bradley D. Thornton Manager Network Services http://NorthTech.US TEL: +1.310.421.8268
On 2021-02-28 15:28, Bradley D. Thornton wrote: > And since we're talking port numbers, that brings up another matter. > Stephanie posted (or maybe I just read it on her page?) about a > collision w/Tivoli on TCP 1965. She referred to it as a 'serious' conflict. Looking on Wikipedia [1], the only mention of port 1965 is Gemini itself. 1: https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers -- Sebastian Alejandro | kayw
IANA claims it's registered to "Tivoli NPM" (presumably Network Performance Monitoring). tivoli.com just redirects to ibm.com, and the Wikipedia page says that Tivoli Software is largely defunct after an IBM acquisition[0]. IBM even seems to have registered new ports for Tivoli after their acquisition of it![1] If it's a big worry, we could try to contact the address given to the IANA[2] and ask if they could "de-assign"[3] their registration. ~nytpu [0]: https://en.wikipedia.org/wiki/Tivoli_Software [1]: https://www.iana.org/assignments/service-names-port-numbers/service-na mes-port-numbers.xhtml?search=IBM+Tivoli [2]: Ivana Cuozzo <Ivana.Cuozzo at tivoli.com> [3]: https://tools.ietf.org/html/rfc6335#section-8.2 -- Alex // nytpu alex at nytpu.com GPG Key: https://www.nytpu.com/files/pubkey.asc Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B https://useplaintext.email/
> On Feb 28, 2021, at 21:04, Phil Leblanc <philanc at gmail.com> wrote: > > Why this specific requirement? I didn't find any reference to > "urn:*:capa". What does it mean and what would be the returned values? Actually, it's optional. Just a way for servers to advertise additional capabilities, such as persistent connections, or chunked transfer encoding. ?0?
> On Feb 28, 2021, at 21:12, Katarina Eriksson <gmym at coopdot.com> wrote: > > Maybe 1961 would have been a better choice? Right you are. ?0?
> On Feb 28, 2021, at 21:21, Alex // nytpu <alex at nytpu.com> wrote: > > I belive it's kind of silly. Ditto . ?0?
On 2/28/2021 1:04 PM, Sebastian Alejandro wrote: > On 2021-02-28 15:28, Bradley D. Thornton wrote: >> And since we're talking port numbers, that brings up another matter. >> Stephanie posted (or maybe I just read it? on her page?) about a >> collision w/Tivoli on TCP 1965. She referred to? it as a 'serious' >> conflict. > > Looking on Wikipedia [1], the only mention of port 1965 is Gemini itself. > > 1: https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers > I believe what you were looking for can be found here: https://www.iana.org/assignments/service-names-port-numbers/service-names-p ort-numbers.xhtml?&page=35 It is however, of little import IMO, and I'm doubtful any Tivoli servers are still out there. We had some of that stuff at Filenet when IBM bought us, basically their vision of LDAP, which was and would be contained within the confines of an Intranet anyway, certainly, not something that would be sharing machinery with Gemini servers lol. BTW, not a lot of folks realize this, but just like Mark Twain was to Samuel Clemens, IANA was pretty much just a nom de guerre of Jon Postel prior to his passing. One guy working out of a single office. ICANN made it an actual body that now either serves, or is served by that bureaucracy. Ergo, my fav RFC of all time: https://tools.ietf.org/html/rfc2468 Jon also wrested control of our DNS back from the Government about a year before he died. Yup! The same Government that's trying to steal it again. It all started with what we call the MoU, and if you're interested there's really good coverage of it in Ellen Rony's 'The Domain Name Handbook'. So don't forget people, it's private property (the Internet, that is - all that copper, fiber, and all those 'Cisco' and Big Iron routers), not public property. Right to pass revocable by owner at anytime. The Government has no Right of way, and as far as imminent domain goes, I'm not sure if the fiber or the racks qualify as real estate. And with that, I'm def going to turn in for the evening and grab a few hours of shuteye. I'm rambling on about things that died in the 90's. I hope that helps :) Kindest regards, -- Bradley D. Thornton Manager Network Services http://NorthTech.US TEL: +1.310.421.8268
On Sun, Feb 28, 2021 at 12:28:07PM -0800, Bradley D. Thornton <Bradley at NorthTech.US> wrote a message of 140 lines which said: > Stephanie posted (or maybe I just read it on her page?) gemini://gemini.bortzmeyer.org/gemini/missing.gmi (sorry to point to a general page, Gemini has no defined semantics for URI fragments, search for "1965") > I checked /etc/services on Debian Bullseye and Slackware -current just > now and don't see port 1965 or Tivoli even mentioned. Debian's /etc/services is not authoritative for port assignment. It is clearly said at the beginning of the file that /etc/services is a
On Sun, Feb 28, 2021 at 04:04:08PM -0500, Sebastian Alejandro <sebastian1231alejandro at gmail.com> wrote a message of 11 lines which said: > Looking on Wikipedia [1], the only mention of port 1965 is Gemini itself. > > 1: https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers Wikipedia is certainly not the authoritative source on port assignments. The IANA registry is.
On Sun, Feb 28, 2021 at 02:32:33PM -0700, Alex // nytpu <alex at nytpu.com> wrote a message of 51 lines which said: > If it's a big worry, we could try to contact the address given to > the IANA[2] and ask if they could "de-assign"[3] their registration. As you can guess, the email address now bounces. I reported that to IANA.
On 3/1/21 2:50 AM, St?phane Bortzmeyer wrote: > Wikipedia is certainly not the authoritative source on port > assignments. The IANA registry is. On 3/1/21 12:44 AM, Bradley D. Thornton wrote: > I believe what you were looking for can be found here: > > https://www.iana.org/assignments/service-names-port-numbers/service-names -port-numbers.xhtml?&page=35 Right, my apologies. Thank you both for pointing me towards the right place to look. I normally use that Wikipedia article to quickly check what's what. I had no clue that the IANA registry list even existed until now. Again, thank you both. -- Sebastian Alejandro | kayw O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
---