Re: Problem with "~user/file.html"
"Daniel W. Connolly" <connolly@hal.com>
Errors-To: listmaster@www0.cern.ch
Date: Wed, 16 Feb 1994 18:41:24 --100
Message-id: <9402161738.AA05710@ulua.hal.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: connolly@hal.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Daniel W. Connolly" <connolly@hal.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Problem with "~user/file.html"
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1470
In message <9402161111.AA03325@ptpc00.cern.ch>, Tim Berners-Lee writes:
>
>Oh dear. You certainly can't do that. The finger protocol is
>that you send a user name and you get back plain text. If you
>return anything else, you are breaking finger. You can't do
>that to existing protocols. You will have complaints from
>finger client users.
>
>Of course, you could define an enhanced "htfinger" protocol, which had a
>header on the response to say what the data type was coming back,
>or a "gofinger" protocol which had a letter prepended to the
>username to say what data type one should expect... :-)))
I disagree. RFC822 says that the body of an internet message is plain
text in the US-ASCII charset. That doesn't stop us from sticking stuff
in internet messages that satisfies the letter of RFC822 and applying
a different interpretation to it -- MIME.
Suppose we leave the normative part of the finger protocol alone,
but we extend our usage of it so that we interpret what comes back
as a text/plain body part, unless by some means (e.g. an HTML link)
we can determine that it should be some other text/* content type.
Note that what comes back still satisfies the constraints of the
finger protocol -- we just interpret it a little differently.
Normal finger clients see some SGML <tags> that they didn't bargain
for, but I don't see much harm in that.
Now folks can't stick image/gif data in their .plan file, but they
can put pointers to them.
Dan