Re: [gopher] Draft RFC
My understanding is that URL: selectors do NOT assume HTTP. Any URL
(except gopher or telnet sessions) can be represented using a URL:
selector. However, they are specified under the h item-type so that
gopher clients which do not specifically understand URL: links can be
served an HTML document which will redirect them. This provides for
some level of support for clients which don't directly understand
URL:. This is a solution which seems to work well (at least in my
limited experience) and I see no reason to alter it.
On 6/21/12, Bradley D. Thornton <Bradley@northtech.us> wrote:
> -----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@gmail.com> wrote:
>>> On 21 June 2012 09:28, Damien Carol <damien.carol@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@gmail.com>
>>>>>
>>>>> On 21 June 2012 04:16, Christoph Lohmann <20h@r-36.net> wrote:
>>>>>> Greetings.
>>>>>>
>>>>>> On Thu, 21 Jun 2012 10:16:05 +0200 Nick Matavka
>>>>>> <n.theodore.matavka.files@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@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@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
>
--
01010111 01101111 01101100 01100110
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
Reply to: