Re: [gopher] Draft RFC
-----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
Reply to: