To: uri@bunyip.com
Subject: Please specify whether the 'protocol' part of a URL is case sensitive
From: Larry Masinter <masinter@parc.xerox.com>
Message-Id: <93Dec17.131941pst.2732@golden.parc.xerox.com>
Date: Fri, 17 Dec 1993 13:19:35 PST
Personally, I think it should be, i.e., 'http:' should be in lower
case, and not 'HTTP:', and 'mailto:' should be allowed but not
'MailTo:'. However, I don't care much as long as the spec specifies it
exactly, lest we get the following kinds of disagreements:
================================================================
Date: Fri, 17 Dec 1993 11:58:30 -0800
Reply-To: lynx-dev@ukanaix.cc.ukans.edu
Originator: lynx-dev@ukanaix.cc.ukans.edu
Precedence: bulk
From: ianf@random.se (Ian Feldman)
To: Multiple recipients of list <lynx-dev@ukanaix.cc.ukans.edu>
Subject: Re: two smaller points (lynx 2-10-12)
X-Listprocessor-Version: 6.0a -- ListProcessor by Anastasios Kotsikonas
X-Comment: LYNX / WWW discussion
Lou Montulli writes:
> No WWW browser I have ever seen will accept
> HTTP://info.cern.ch/default.html. LibWWW will not process a URL
> that looks like HTTP://... So knowing that do you really want
> me to change Lynx to accept HTTP://...? That way we can add one
> more way for someone to make a mistake and not know they made one.
No, of course not, the way I read the URL specs it appeared
as if both the 'HTTP' (which is how the protocol is usually
spelled when referred to in text) and 'http' usage was acceptable.
I a sorry to hear that the LibWWW disallows --for no good reason
the way I see it-- the former and requires here all-lower case
'scheme' while the 'path" part of the url-string can be in mixed
case. It is too bad that the URL specs make a case distinction
in the use of 'generic' and the other addressing forms, permit
in the former, disallow in the latter ones.
> Because you will write your HTML using Lynx and everything will
> work, but as soon as someone uses Xmosaic or the linemode browser
> the links won't work.
No, of course not, that would be like explicitly locking out
non-Lynx users everywhere (but, when you think about it, maybe
that's the way to HAVE THE ENTIRE WORLD EATING OUT OF YOUR PALM ;-))
Still, this leads to a wider question... what if the other
browsers do not behave correctly in all respects either? Should
development of the Lynx be checked against behaviour in the
other shells, against possibly improper library code or against
the existing standards? Standards, in this case
file://info.cern.ch/pub/www/doc/url7a.txt
that to my eyes do not prohibit the use of UPPERCASE scheme.
To review this again (partial BNF syntax table):
_______________ ____________________________________________________________
url generic | httpaddress | ftpaddress | newsaddress |
prosperoaddress | telnetaddress | gopheraddress |
waisaddress
generic scheme : path [ ? search ]
scheme ialpha
ialpha alpha [ xalphas ]
alpha a | b | c | d | e | f | g | h | i | j | k |
l | m | n | o | p | q | r | s | t | u | v |
w | x | y | z | A | B | C | D | E | F | G |
H | I | J | K | L | M | N | O | P | Q | R |
S | T | U | V | W | X | Y | Z
[....]
path void | xpalphas [ / path ]
xalpha alpha | digit | safe | extra | escape
xalphas xalpha [ xalphas ]
xpalpha xalpha | +
xpalphas xpalpha [ xpalpha ]
[....]
> Try it out in your line-mode browser if you don't believe me.
I stand corrected.
> The situation with MailTo: is this. I don't pass mailto URL's
> to the Web library so I could accept MailTo: as a valid URL very
> easily, but if I do, chances are that the link won't work for
> any other browser but Lynx. Lynx may have accepted "MailTo"
> in the past, but it was wrong.
Actually, I'd say it was _correct_, not wrong, to permit that,
albeit I understand your wish to conform to what the other tools
find acceptable. In that case there's not much that can be done
but use the "mailto:" form. I will, however, be bringing this
matter up to the attention of the Webgods, because this in my view
constitutes a needless spelling restriction where none is called
for. So maybe you'll be able to change back to the much more
_self-evident_ MailTo: in the future.
__Ian