Content-type: text/plain; charset=iso-8859-1
From: Timm Murray <hardburn@runbox.com>
To: gopher@complete.org
Subject: [gopher] Re: Encouraging MIME types
Date: Mon, 16 Sep 2002 21:55:54 -0500
References: <200209142214.35897.hardburn@runbox.com>
 <20020916023229.GB25785@complete.org>
In-Reply-To: <20020916023229.GB25785@complete.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200209162155.58117.hardburn@runbox.com>
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 15 September 2002 21:32, John Goerzen wrote:
> On Sat, Sep 14, 2002 at 10:14:32PM -0500, Timm Murray wrote:
> > text/text will still have a type of '0', GIF files will still have a type
>
> I assume you mean text/plain.

Oops, you're right.

>
> > of 'g', etc.  Note that files with similar types would *not* use the
> > standard Gopher types.  For instance, a text/html document would never be
> > sent as a Gopher type of '0'.
>
> text/html is type 'h' anyway.  However, type 0 is defined to include more
> than you are defining it to mean.

Yes.  I am intentionaly redefining the '0' type to be only text/plain 
documents.

Where was the 'h' type defined?  It wasn't in RFC 1436, and I didn't see it in 
the Gopher+ doc, either.

>
> > 2)  A new Gopher type, 'm', is to be implemented which tells a client to
> > check the MIME type in the Gopher+ space.
>
> A Gopher+-aware client should already be doing this; there is no need to
> explicitly tell it to.

Perhaps.

>
> > 3)  The 'I' type is to be either completely deprecated or used as a
> > synonym for 'm'.  GIF files can still use the 'g' type, but any other
> > images should be sent with the 'm' type and their proper MIME type.
>
> This breaks backwards compatibility, I suspect.

That's the point.  I'd like to progressivly destroy the item type field.  I 
figured that the seperation of GIF files and other image types doesn't make 
sense anymore, so the 'I' attribute would be a good place to start for type 
field deprecation.  The 'g' type is only kept for the benifit of Gopher0 
clients.  For now.

>
> > 4)  No new Gopher types are to be defined--MIME types are to be used as a
> > complete replacement.  The only possible exception to this is for
> > research purpases, but even then, MIME types are encouraged.
>
> I can agree with that :-)
>
> However, overall, I don't really see any benefit to the 'm' type or the
> change in meanings for '0' and 'I'.  Gopher+ clients should already be
> using the Gopher+ attributes (in fact, since views permit one menu entry to
> actually have multiple MIME types, they *must*).  Gopher0 clients are still
> left with the single-character types, which I agree are a nasty thing.  I
> don't see what purpose breaking some of the gopher0 clients will serve, I
> guess.

It gives a clear indication of what's being actively worked on and what is 
becoming stale.  I basically assume that if a client is not at Gopher+ now 
(or won't be there soon), it's not being activly worked on and should be 
ignored.

- -- 
On two occasions I have been asked [by members of Parliament!], "Pray, Mr. 
Babbage, if you put into the machine wrong figures, will the right answers 
come out?"  I am not able rightly to apprehend the kind of confusion of 
ideas that could provoke such a question.
		--Charles Babbage
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj2Gmb0ACgkQqpueKcacfLTu6gCfT3Wts1ZsNSd5/Ch76/hWYLRQ
X8kAnjRjRtxZPi+z6C7kXdIwwRMMkKKI
=dSJU
-----END PGP SIGNATURE-----