[gopher] Draft RFC
Damien Carol
damien.carol at gmail.com
Fri Jun 22 05:46:31 UTC 2012
I said "agree" to some stuffs but I will make a more constructive comment.
I'd not finshed document analysis.
2012/6/22 Bradley D. Thornton <Bradley at northtech.us>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
>
> On 06/21/2012 09:13 AM, Wolfgang Faust wrote:
>
> > * The redirect is for clients which don't support URL: links but which
> > do support HTML. They will be sent to the correct location so that
> > they're not left wondering what went wrong.
>
> Isn't this best left as a function for clients?
>
> I'm just throwing this out there, and could be wrong, yet it seems to be
> that URL is for URL and not for HTTP or <a href=http://blah></a>
>
> In my thinking, and historically so, Microsoft started the trend on
> making browsers braindead. Before the netscape wars you could reliably
> expect a level of competence from the user. Sure, (and I think it was
> Netscape that actually introduced it), you could declare a host whose
> name began with 'www.sld.tld' on the address bar and the browser would
> assume that you meant 'http://www.sld.tld', but that was simply because
> convention dictates that a host named 'www' is typically a service
> listening on port 80.
>
> Even now, we enter 'gopher://host.sld.tld/....' (An URL)
>
> and should we (inhabitants of the planet Earth) pay the price for
> Microsoft's policy of "Embrace, Extend, Extinguish" by permitting the
> user to become so stupid as to not know that:
>
> ftp://host.sld.tld is different from http://host.sld.tld - even if (I'm
> not certain of this anymore) the hostname you placed on your browser's
> address bar would be converted to ftp://ftp.sld.tld if you entered
> 'ftp.sld.tld'?
>
> But that's why the protocol in the string on the address bar....
>
> I may have a an FTP server called jikjau.sld.tld and an HTTP server
> called chickensau.sld.tld.
>
> What about:
>
> irc://chat.freenode.net (an URL)
>
> skype://tallship/chat (an URL that leads to me)
>
> or some other URL.
>
> I'm really not comfortable with solutions that defer to HTTP as *the*
> definition of an URL, much less a proposed standard that does, by
> assuming that a client's lack of understanding of URL somehow assumes
> that it is the server's job to redirect with an HTTP URL....
>
> If that's what your saying in the RFC draft WIP.
>
> And yes, I think it would be best to make sure it's formatted in RFC
> format too ;) After all, that's how it's going to need to be submitted.
>
> I applaud your effort and see some good stuff there. I also believe that
> we *may* enjoy some benefit from publishing an RFC draft - but having
> served on many task forces, steering committees, and working groups for
> the IETF, IRTF, and IRSG of the IETF and IAB, I both caution and urge
> the entire group here NOT to submit such a draft in haste, as there is
> obviously much more consensus to be reached here, understanding between
> the party's involved, and indeed some maturation of the notions which
> will be proposed in such a draft RFC.
>
> I'm also glad that Chris Lohmann elaborated upon his objections and why
> - - so many people just offer a, "Yeah me too", or a "I don't like that" -
> which is fricken worthless towards achieving a goal. Those people might
> as well not even bother commenting.
>
> Why nots, and Alternatives are also very important in such a process.
>
> We've ventured into territory that I believe is outside the scope of
> what this list was originally intended - but that's okay, as long as we
> understand that at least some threads on this list moving forward are
> going to be functionally the equivilant of an IETF working group or
> steering committee - which demands a slow, methodical plodding along in
> order to produce truly wonderul results.
>
> A few weeks of hard work is to be appluaded, but IMSHO doesn't rise to
> the standards of producing such truly wonderful results - it is a start
> towards that.
>
> I hope I have not offended anyone or caused any undue tl;dr's :)
>
> > The example redirect is malformed HTML -- I thought I fixed it on the
> > Google Doc but I can't find the revision anywhere. It seems that it
> > was mangled by the original email transmission and nobody noticed
> > (including me) because it looks OK at first glance. The valid HTML is:
> > <HTML>
> > <HEAD>
> > <META HTTP-EQUIV="refresh" content="2;URL=http://www.example.com/">
> > </HEAD>
> > <BODY>
> > You are following an external link to a Web site. You will be
> > automatically taken to the site shortly. If you do not get sent
> > there, please click
> > <A HREF="http://www.example.com/">here</A> to go to the web site.
> > <P>
> > The URL linked is:
> > <P>
> > <A HREF="hhttp://www.example.com/">http://www.example.com/</A>
> > <P>
> > Thanks for using Gopher!
> > </BODY>
> > </HTML>
> >
> > On 6/21/12, Nick Matavka <n.theodore.matavka.files at gmail.com> wrote:
> >> On 21 June 2012 09:28, Damien Carol <damien.carol at gmail.com> wrote:
> >>> I agree, every modern server I saw have "about" node and many have
> >>> "robots.txt" and "caps.txt".
> >>>
> >>> I think you should consider writing your document in "RFC" format.
> >>>
> >>> Many RFC only formalize use of techs like robots.txt.
> >>>
> >>>
> >>> 2012/6/21 Nick Matavka <n.theodore.matavka.files at gmail.com>
> >>>>
> >>>> On 21 June 2012 04:16, Christoph Lohmann <20h at r-36.net> wrote:
> >>>>> Greetings.
> >>>>>
> >>>>> On Thu, 21 Jun 2012 10:16:05 +0200 Nick Matavka
> >>>>> <n.theodore.matavka.files at gmail.com> wrote:
> >>>>>> Hello, world!
> >>>>>>
> >>>>>> Having spent several weeks writing this, I believe that the draft
> RFC
> >>>>>> is just about ready to be published. Without further ado, allow me
> >>>>>> to
> >>>>>> present the new Gopher specification! Unless anyone says otherwise,
> >>>>>> this is what will get published.
> >>>>>>
> >>>>>> http://piratepad.net/gopher
> >>>>>> [snip ... too long signature]
> >>>>>
> >>>>> I am against this draft:
> >>>>> 1.) The caps file shouldn't be in the *protocol* specification.
> >>>>> 2.) robots.txt shouldn't be in the *protocol* specification.
> >>>>> 3.) about.txt shouldn't be in the *protocol* specification.
> >>>>> 4.) The definition of the full stop termination of text files in
> >>>>> this draft does not solve anything. It can be sent as before
> >>>>> and clients have to take some magic to know if it is part of
> >>>>> the content or the transfer protocol.
> >>>>> 5.) Why is there a need to include the HTTP error codes? Item type
> >>>>> 3 and predefined strings should simplify it.
> >>>>> 6.) Who uses this TITLE stuff?
> >>>>> 7.) According to that draft proposal it is possible to have the
> >>>>> URL: redirections in every selector. This would create much
> >>>>> confusion without the »h« item type in conjunction.
> >>>>> 8.) Servers still have to provide the redirection hack. This draft
> >>>>> does not solve anything there.
> >>>>> 9.) Why is there a definition of a redirect page? Why are people
> >>>>> restricted in it? Couldn't it just be avoided?
> >>>>>
> >>>>> My conclusion is, that with that draft in action gopher is nothing
> >>>>> else
> >>>>> but a simplified HTTP with hacks and more unspecified behaviour.
> >>>>>
> >>>>>
> >>>>> Sincerely,
> >>>>>
> >>>>> Christoph Lohmann
> >>>>>
> >>>>>
> >>>> If caps and robots shouldn't be in the protocol specification, where
> >>>> does one standardise such things? Several people actually
> >>>> Google-Doced that these things must be there.
> >>>>
> >>>> What I am seeking to do is take a snapshot of Gopher as currently
> >>>> used, and there's no question that caps and robots are currently used.
> >>>>
> >>>> If I were to implement your changes, there would be nothing left but
> >>>> effectively the 1991 version of gopher.
> >>>>
> >>
> >> Mr Carol, just whom do you agree with? Me or Mr Lohmann?
> >>
> >> --
> >> /^\/^\
> >> \----|
> >> _---'---~~~~-_
> >> ~~~|~~L~|~~~~
> >> (/_ /~~--
> >> \~ \ / /~
> >> __~\ ~ / ~~----,
> >> \ | | / \
> >> /| |/ | |
> >> | | | o o /~ |
> >> _-~_ | || \ /
> >> (// )) | o o \\---'
> >> //_- | | \
> >> // |____|\______\__\
> >> ~ | / | |
> >> |_ / \ _|
> >> /~___| /____\
> >>
> >> _______________________________________________
> >> Gopher-Project mailing list
> >> Gopher-Project at lists.alioth.debian.org
> >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
> >>
> >
> >
>
> - --
> Bradley D. Thornton
> Manager Network Services
> NorthTech Computer
> TEL: +1.310.388.9469 (US)
> TEL: +44.203.318.2755 (UK)
> TEL: +41.43.508.05.10 (CH)
> http://NorthTech.US
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Find this cert at x-hkp://pool.sks-keyservers.net
>
> iQEcBAEBAwAGBQJP49PIAAoJEE1wgkIhr9j3pjwH/27uXJAsXYlDeM6vq9rEDBti
> fMxbFXE1FAnP2TSrd5yidMdlbgggPYUWpGaJv6grMaGMP6XjCs+vpGP2Hirn7mI6
> nAZ52HvG5heSmsyCnm1lRq7aSEF4F4kQ67bMsLXh0JdFIwzflhUM//8aI6sPAebx
> +COKuAuiHo++b75MtszUpUhh5vpnmE9bGTu6TmbU6UruQGKdUSNm2F0AmGAHUe/+
> 6qwZDf5kIreNkTwGiIKRg16R0esH7gv50IA3psmH0xR19OQhygXnjNKPSTxqTKvf
> s6tWHwNQFsyl+dj12LP+hrjUAF7BoucnSIrfXeukMwwSKjV/Tf6GlQ8wiH1PqUM=
> =TBpu
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Gopher-Project mailing list
> Gopher-Project at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
>
--
Damien CAROL
gopher://dams.zapto.org/1/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/gopher-project/attachments/20120622/8a5909b5/attachment-0001.html>
More information about the Gopher-Project
mailing list