Subject: [apps-discuss] gopher-ii standardization process & personal introduction

From: Edward Vielmetti <[email-masked]>
Date: Tue, 9 Jun 2015 14:31:44 -0400

After a message on the gopher-discuss list I decided to join the
apps-discuss list and see what I could do for the gopher-ii standardization
process.

By way of background, I've contributed to RFCs from the early 1990s
including MIME (1341, 1521, 2049), Guide to Network Resource Tools (FYI
23),  Network Access to Multimedia Information (1614, RARE 8), and Uniform
Resource Locators (1738).

I gave a presentation at GopherCon '92 and Prentiss Riddle wrote up the
whole thing here:

http://vielmetti.typepad.com/vacuum/1992/08/gophercon-92-trip-report-from-prentiss-riddle.html

The history of Gopher is that of a protocol that has had a lot of utility
at various times in its life. I'm looking at it as a possible lightweight
information system for Raspberry Pi sized devices (small single board Linux
systems, sub $25 delivered cost). IETF has COAP in that space already, but
perhaps Gopher and gopher-ii can live there too, if you have a system
constrained enough to be performant on suitable equipment as well as secure
enough because of a deployed base of well-understood and well reviewed code.

I'm currently at All Hands Active, a maker space in Ann Arbor, and I'm
subscribing to this list via a daily digest so don't expect more than a
message a day from me.

thanks

Ed
-- 
Edward Vielmetti +1 734 330 2465
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 11 Jun 2015 07:49:58 -0000

>apps-discuss list and see what I could do for the gopher-ii standardization

Hi.  Long time, no see.

> I'm looking at it as a possible lightweight

Gee, I wish someone had given us this background a month ago.  I get
your point, but Raspberry Pi runs linux and it's hard to believe that
a lightweight web server like lighttpd wouldn't work perfectly well
and be comparably secure since its code gets a lot of scrutiny.  If
you want a client, there's always lynx.

CoAP is intended for really tiny things, with the usual example being
to tell a smart lightbulb to turn itself on.  Gopher seems too heavy
for that.

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 11 Jun 2015 16:05:39 +0100

> I'm not worried about clients on tiny machines, lynx supports Gopher just
> fine. I'm more worried about reasonable client-server arrangements where
> the server is a $25 Raspberry Pi or even a $3 ESP8266 (which talks MQTT
> just fine, as I understand it, and for which it would be perfectly
> cromulent to get a Gopher server running on.) If you're going to run HTTP
> you want to proxy it anyway through some service that scales up to web
> scale, because the internet will crush your puny web server.

I still don't get it.  The Internet will only crush your server if a lot 
of random places send requests to which you send expensive replies.  On 
the wire, http and gopher are essentially the same, open a TCP session, 
send a blob of request, the server sends a blob of result, and you're 
done.  There's all sorts of extra optional bells and whistles in http, but 
you don't have to support them if you don't want to.  Take a look at 
Mongoose, a minimal web server intended for embedded applications, 5600 
lines of source code.

If you want to keep tourists from hammering on your web server, you do 
that by keeping spiders away from it.  Running it on another port works 
pretty well.

It's still very unclear to me what practical problem is addressed here 
that existing tools don't.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 11 Jun 2015 17:25:00 +0100

John R Levine writes:
> It's still very unclear to me what practical problem is 
> addressed here that existing tools don't.

You sound like a windows user who doesn't understand why anyone would use 
(or even work on!) those unix things when windows does the job.

(I don't see why they do it either. But they clearly have running code and 
roughly agree on the protocol to use.)

Arnt

---

From: Edward Vielmetti <[email-masked]>
Date: Thu, 11 Jun 2015 10:16:27 -0400

John -

CoAP is intended for really tiny things, but in practice a lot more people
use MQTT (an OASIS protocol) which is a publish-subscribe protocol. A very
tiny Docker container for MQTT running mosquitto -

https://registry.hub.docker.com/u/lapax/tiny-mosquitto/

is a reasonable design and consumes only a few megabytes. A system like
Node-RED from IBM runs that nicely as its inter-machine communcation and
fits on a Pi or a Beaglebone reasonably well.

That said -

HTTP/HTML5 is a pretty big protocol, and Gopher (even gopher-ii) is a much
smaller protocol. The minimum Docker image serving up a Gopher server is a
good design target - you just expose port 70, do just your tiny little
thing, and don't try to construct an entire web service out of it (and
track HTML5 etc etc ad nauseum).

As to the comments about retrocomputing, just note that the Pi and the
Beaglebone and their ilk are two orders of magnitude cheaper than the
computers of the 1990s that are contemporaneous with Gopher, and roughly
comparable in power. Rewinding the protocol stack back to 1992 and building
out from there with what we learned in the intervening 23 years is a
reasonable exercise. At minimum it gives us a secure base to build from for
April Fools.

thanks

Ed

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Jun 2015 09:32:20 -0700

Edward, and any other lurkers in general:

> subscribing to this list via a daily digest so don't expect more than a

You don't appear to be subscribed at all, because your messages keep
getting caught in moderation.  Please make sure you confirm your
subscription if you intend to participate.  Posts that get stuck in
moderation can take a while to get cleared, which messes with thread order,
and might even expire in the very rare event that we don't get to them
quickly enough.

If you need help getting subscribed, please drop a note to
[email-masked] or [email-masked].

-MSK, apps-discuss moderator

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Jun 2015 18:38:08 +0200

On 11 Jun 2015 at 18:29:02, Edward Vielmetti ([email-masked]) wrote:
$3 ESP8266 (which talks MQTT 
just fine, as I understand it, and for which it would be perfectly 
cromulent to get a Gopher server running on.)

Waste of energy; the ESP8266 runs CoAP just fine as well.

cs=coap.Server()
cs:listen(5683)

myvar=1
cs:var("myvar") -- get coap://.../v1/v/myvar will return the value of myvar: 1

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Thu, 11 Jun 2015 18:53:14 +0200

On 2015-06-11 16:16, Edward Vielmetti wrote:
> John -
>
> CoAP is intended for really tiny things, but in practice a lot more
> people use MQTT (an OASIS protocol) which is a publish-subscribe
> protocol. A very tiny Docker container for MQTT running mosquitto -
>
> HTTP/HTML5 is a pretty big protocol, and Gopher (even gopher-ii) is a
> much smaller protocol. The minimum Docker image serving up a Gopher
> server is a good design target - you just expose port 70, do just your
> tiny little thing, and don't try to construct an entire web service out
> of it (and track HTML5 etc etc ad nauseum).
> ...

HTML5 is huge, HTTP/1.1 without optional parts is not.

Maybe it would be more interesting to define media types for Gopher 
interactions and run them over HTTP/1.1 with GET and POST?

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Jun 2015 15:49:11 -0400

--On Thursday, June 11, 2015 18:53 +0200 Julian Reschke
<[email-masked]> wrote:

>> HTTP/HTML5 is a pretty big protocol, and Gopher (even
>> gopher-ii) is a much smaller protocol. The minimum Docker
>> image serving up a Gopher server is a good design target -
>> you just expose port 70, do just your tiny little thing, and
>> don't try to construct an entire web service out of it (and
> Maybe it would be more interesting to define media types for
> Gopher interactions and run them over HTTP/1.1 with GET and
> POST?

As I read the earlier postings, I was thinking about something a
little bit similar.  Let ask a different question or pair of
questions (with the understanding that these are questions --
I'm not trying to advocate anything.  Please forgive me if this
is naive - I'm trying to ask questions that are close to
end-user level.

It seems to me that "Gopher", as seen by end users is a pair of
things: an access protocol and a hierarchically-organized
distributed information model.  From the same point of view, the
Web is an access protocol and a mesh (and/or hypertext)
distributed information model.  There is a principle in graph
theory that one can use a mesh to simulate a hierarchy but not
vice versa.  At the same time, that simulation inherently makes
resource that are thought of in hierarchical terms harder for
non-experts to organize and think about.

If that is correct, should we be thinking about one or both of:

(1) A media type and/or markup structure that is optimized for
hierarchical menu-like structures and that is very easy to use
rather than, e.g., laden with options for doing really fancy
things in a mesh environment.  I don't know what that structure
would be; I'm fairly sure it isn't unrestricted HTMP5 even
though HTML5 could almost certainly be used to simulate it?

FWIW, it is fairly clear to me that such an arrangement should
provide --either directly or via a well-defined URN-like
arrangements-- for alternate locations/ copies of the same
resources, both menus and targets, so this wouldn't be a
completely trivial subset of HTML.

(2) A profile of, or variant on, HTTP that would be really
lightweight and that might, if necessary or useful, be optimized
somewhat toward the above data type in the same ways that HTTP
itself has historically tended to assume HTML.  Maybe that
subset would be HTTP 1.1, as Julian suggests, but maybe it would
be sensible to look at, e.g., current thinking about security
and privacy and avoid, again for example, separate "insecure"
and "secure" protocols on different ports in favor of SASL-like
negotiations.

Now, even if the above are just thought experiments, are they
useful in figuring out what "Gopher-II" means and where it would
fit into both user and restricted device or application models?

Again, just questions to see if we can clarify and converge a
bit on our thinking.

       john

p.s. Hi, Ed.

---

From: "John Levine" <[email-masked]>
Date: 11 Jun 2015 22:18:43 -0000

>distributed information model.

It's also a mesh -- entries in a gopher menu can point anywhere.  Back
in the dim mists of the 1990s I recall briefly using a server that
served both gopher and web from the same set of files.  The menus
turned into either gopher menus or simple web pages with lists of
links.  Everything else was just content which it served more or less
the same either way.  Poking around in gopherspace, I see several
gopher servers available that appear to do roughly the same thing.

It seems to me that a simple profile of http would do everything that
gopher2 is intended to do, require about the same server resources,
and be usable in a lot more clients.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Jun 2015 23:59:41 -0400

--On Thursday, June 11, 2015 22:18 +0000 John Levine
<[email-masked]> wrote:

>> It seems to me that "Gopher", as seen by end users is a pair
>> of things: an access protocol and a hierarchically-organized
> It's also a mesh -- entries in a gopher menu can point
> anywhere. 

But the menu is, IIR, pretty strictly hierarchical.

> Back in the dim mists of the 1990s I recall briefly
> using a server that served both gopher and web from the same
> set of files.  The menus turned into either gopher menus or
> simple web pages with lists of links.  Everything else was
> just content which it served more or less the same either way.
> Poking around in gopherspace, I see several gopher servers
> available that appear to do roughly the same thing.

Again, from and information theory/ graph theory viewpoint, or
even a database one, one can always use a mesh to simulate a
hierarchy, but that doesn't mean that hierarchies don't have
conceptual advantages.  One might draw a partial analogy to the
POP3/IMAP4 relationship: there are few POP3 servers these days
that are not just an alternate protocol interface to an IMAP
server, serving the same mailstore.  With a decent
implementation of OFFLINE mode, an IMAP server can simulate
anything a POP3 server can do, which is one of the reasons those
"two protocols, one implementation, one mailstore" approaches
work.  And yet I haven't heard anyone arguing for deprecating
POP3, definitely not with some of the vehemence that has been
applied to gopher.

That doesn't imply to me that we need a 21st century gopher
protocol as distinct to a carefully-thought-out HTTP protocol or
HTTP variant ("THTTPS", anyone?).  However, I think the more we
understand the issues, the better off we will be..

> It seems to me that a simple profile of http would do
> everything that gopher2 is intended to do, require about the
> same server resources, and be usable in a lot more clients.

Conversely, given the above, is it possible that an HTTP server
could be modified to support something gopher-ish as well as
HTTP and HTTPS?  Would there be any advantage in that?  

"Usable in a lot more clients" is not something I've heard Nick
or Ed ask for, although I may have missed something.   That is,
in a different way, my question.  It seems to me that Ed, at
least, is arguing that there are advantages in a constrained,
lightweight, special purposes protocol.  That might (or might
not) make having dedicated/specialize clients an advantage
(i.e., more general-purpose clients a disadvantage) even if
there was little or know performance advantage.  I don't know,
but don't want to leap to conclusions here... or start
pretending that HTTP/HTML are a universal hammer for swatting
any possible problem.

    john

---

From: "John Levine" <[email-masked]>
Date: 13 Jun 2015 22:26:21 -0000

>But the menu is, IIR, pretty strictly hierarchical.

No, really, it's a mesh.  A gopher menu is a list of pointers to
anywhere.  Within a single site it tends to be mostly hierarchical but
sites point to each other with the same lack of structure they do on
the web.

>understand the issues, the better off we will be..

Agreed.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sat, 13 Jun 2015 21:57:16 -0400

Ever do FTP via TELNET/RLOGIN and/or RS232 communications?

   FTP SERVER <----> FTP CLIENT <--- TELNET/RLOGIN, DIALUP/ANSI/VT10x, 
X.25 --> XYZ, KERMIT CLIENTS

Cross industry, enterprise, corporations, mission critical, high 
security operations still alive using strong legacy communication 
protocols.

Ciao

-- 
HLS

On 6/13/2015 6:26 PM, John Levine wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>