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
>