Date: Wed, 30 Mar 94 19:00:21 +0200
From: Tim Berners-Lee <timbl@ptpc00.cern.ch>
Message-Id: <9403301700.AA00480@ptpc00.cern.ch>
To: uri@bunyip.com
Subject: URL decisions in Seattle, & changes
Note: THESE ARE NOT OFFICIAL MINUTES
They are my notes on URLs only ... I put them up here only to allow people
to correct me, and to optionally help the minute writer.
Gopher:
The gopher string wants to use the "?" and "/" characters (which
in WWW have convention syntax role) within a string without any
special role. This was upheld, so slashes and ? may be put into
a URL without being encoded. The characters are still in the
reserved set, but in Gopher, / and %2F have the same effect.
FTP:
Multiple CWD interpretation of FTP is as in the 03 spec but
changes are:
- Directory access spacified by trailing slash, not type
- Spaces in type field are omitted
(Karen Sollins pointed out CWD though protected directories
won't work.)
News:
(some disquiet over BNF allowing illegal characters in
newgroup names was squashed)
No change.
SECURITY:
Security concerns should be made more explicit. I have
done this subject to comments fropm many that the spec should
only point out security hazards, and cannot madate that people
don't do stupid things.
ERIK:
Erik says a spec with unresolved issues should never be submitted
for consideration as a standards track RFC.
Erik says he felt the spec was unclear, but he won't say
where he felt it was unclear until it is put up to the IESG (!).
New versions
As editor I was asked to submit draft 03 as it currently stands (done)
and 04 when the meeting's changes were in, and 05 when Erik's
"tightening up" had been done. Erik charged Tim BL, Ned Freed,
Mark McC and Larry M with doing the tightening.
Changes:
I have made the following changes:
1. ftptype has nwe production in BNF
2. ftp type changed in text to indicate space omitted
3. ftp directory trailing slash documented (no BNF change)
That's all I can find in my notes which changes the URL spec
but I've probably forgotten something in my sleep or missed
it in an MBONE dropout... so if you think
of something mail me.
I am officially on holiday this week but I'll wait for
the minutes and comments anyway before doing draft 04.
_____________________________________________________________
CLEANING UP
1. Minor correction to xalphas production in BNF.
2. (Hypertext version has more links all over the BNF).
3. Major rewriet of Gopher section
The gopher section isn't clean as it is. It is neither
a transparent reference to the Gopher spec, nor is it a
complete definition of the gopher commands. It is a set
of examples which still are not unambiguous (I couln't build a BNF
from them) which give one no idea of what characters are
or are not allowed. It is also not clear why the trailing CRLF is not
encoded in the URL, unless there are embedded CRLFs, in which
case the trailing CRLF is also explicit, when plusses are part of
strings, whether %09 after a search string must always be included
if the search string is there but there is no g+ stuff, etc, etc.
I don't think this spec is the right place for this
information anyway.
Under the "cleaning up" mandate I would propose that the
whole thing be reworded [dramatically] to read:
==========================================================================
The gopher URL, after an initial double slash, specifies
the host and optionally a colon and the port to which the
client should connect. This is followed by a single slash
and a single gopher type character. This type code is used
by the client to determine how to interpret the server's
reply and is is not for sending to server. The command
string to be sent to the server immediately follows the
gopher type character. It consists of the gopher selector
string followed by any extra "Gopher plus" syntax, but
always omitting the trainling CR LF pair. When the gopher
command string contains characters (such as embedded CR LF
and HT characters) not allowed in a URL, these are encoded
using the conventional encoding.
[as before] Note that some gopher selector strings begin with a copy of the
gopher type character, in which case that character will occur twice
consecutively. Also note that the gopher selector string may be an empty
string since this is how gopher clients refer to the top-level directory on
a gopher server.
If the encoded command string (with trailing CR LF stripped) would be void
then the gopher type character may be omiited and "1" (ASCII 31 hex) is
assumed.
[as before]Note that slash "/" in gopher selector strings may not correspond
to a level in a hierarchical structure.
=====================================================================
Otherwise, if we don't use this method,
1. The gopher+ stuff has to be made much more tight;
2. The gopher+ spec will be constrained by the URL spec;
3. The URI working group wll have to verify the whole gopher+
protocol.
I await input on other cleanliness from the allocated hygiene experts
(Ned, Mark, Larry). I'd also like Dan Connolly's input on the
grammar -- in which places is it ambiguous in its current form, Dan?
Reminder for Mosaic-touting URL dudes: for your hotlist
http://info.cern.ch/hypertext/WWW/Addressing/Addressing.html
for the current-est annotated spec, and pointers to all other UR* resources I
know of.
Tim