Date: Wed, 30 Mar 94 13:20:50 CST
Message-Id: <9403301920.AA23318@boombox.micro.umn.edu>
From: "Mark P. McCahill" <mpm@boombox.micro.umn.edu>
To: timbl@www0.cern.ch, uri@bunyip.com, connolly@hal.com
Subject: Re: URL decisions in Seattle, & changes
In message <9403301700.AA00480@ptpc00.cern.ch> writes:
> 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.
>
Tim,
To make it easy for al of us to work on tightening this up, let's make
sure we keep producing ascii text version as we go. We can't submit an HTML
document as an RFC.
I plan to make a clean up pass through the gopher section in the next couple
days, and then make a grand tour through the whole document after that.
> _____________________________________________________________
> 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.
And I don't think you included the reference to the Gopher+ spec I gave you,
and we really ought to refernce the Gopher Informational RFC for the base
gopher stuff (and I'm not sure we are doing that)...
> It is a set
> of examples which still are not unambiguous (I couln't build a BNF
> from them)
but I can and will :-) :-) :-).
> 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.
As I said before we need to explicitly state how items in the URL map to
actions a client takes to resolve the URL, so you end up explaining which
actions in the protocol you take for a given URL. I'll make another editing
pass and see if I can come up with something better than what is there now.
One spot is really confusing because a line got dropped somehow...
> ...
> 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'll take care of a cleanup of the gopher section and a BNF to go with it.
BNF is always the last thing to get sorted out anyway...
> 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.
>
I talked to one of the other URL spec sanitizers yesterday (Larry Masinter) and
its best and easiest for both Larry and me if there is an ascii text document
to work from. When you make a set of changes can you please, please, please
extrude an ascii document each time so we have something that is in the same
format that the RFC is going to be in?
Mark P. McCahill
gopherspace engineer/University of Minnesota
mpm@boombox.micro.umn.edu
612 625 1300 (voice) 612 625 6817 (fax)