Date: Mon, 11 Jul 94 16:57:41 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9407111457.AA01728@www3.cern.ch>
To: masinter@parc.xerox.com
Subject: Re: questions on URL draft
================================================================
1. Add ">" to the list of characters that are `universally reserved'
and must be encoded in all URLs). [Used for terminating <>]
acceptable. See 2.
2. Add "<", ">", and """ (doublequote) to the list of characters
that are universally reserved. [as with 1, but be safe]
acceptable [but flawed. Reserved characters have special
meanings. These don't. You just need to remind people that
these characters are unsafe in some but not all of cases.]
3. Remove `wais:' scheme from this draft. [not well enough defined?]
acceptable
4. Add `local-file:<path>' as a URL that references a local file.
[one opinion]
unacceptable.
5. Add `file:<path>' as a URL that references a local file. [closer
to current practice]
acceptable/unacceptable. [I mean it'll work but 6 is better
with a specification that a void host means the local host:
this gives you best of both worlds.]
6. Add `file://<host>/<path>' as a URL that references a local file
when referenced from <host>. [as per TimBL]
preferable, assuming tranbslation into / form is specified
as per current practice.
7. Include `file://localhost/<path>' in file URLs. [as per TimBL]
[ Clarification: in libwww code, void host is acceptable just
as //localhost/ is, but the library will try to insert the
real host if possible, to avoid confusion, unless localhost
has been specified.
8. Add `&' as a `reserved' character. [used in forms response]
9. Add `&' as a `reserved' character, and describe its use in the
URLs that result from encoding the value of HTML forms. [more
writing]
10. Assert that no new URL scheme can reserve any characters that are
not listed as `reserved' in this document. [allows gateways
to know what can be escaped without loss of semantics; restricts
future schemes as to which chars can be reserved]
preferable. (essential)
11. Add an Appendix B that describes `relative URLs' in this document.
Don't mind. You can always refer to RFC1630, but that is only
informational.
12. Move the "URL:" prefix requirement to the (first) Appendix as a
recommendation for URLs `in plain text'.
preferable.
13. Assert that `scheme' names are case insensitive (e.g., HTTP: is
equivalent to http:). [I think we discussed this but don't
remember a consensus]
unacceptable. [Current W3 code is sensitive. Can change
but legacy of existing browsers won't grok. Is it worth
changing? Just make another thing to cannonicalize?]
14. Limit `scheme' names to lowercase ASCII letters, digits, plus,
hyphen and underscore, with no encoding. [as proposed]
preferable.
15. Remove the recommendation for using "x-" scheme names. [as proposed]
don't mind.
17. add a mailserver: URL to this document, which corresponds to
message/external-body with the "phantom body" URL encoded.
(if there is some consensus for this, we will need to define
the syntax). [as proposed]
unacceptable. An attept to operate on (retrieve) any other
URL (including mailto:) produces a result as expected, but
as there is no protocol for mail servers which allows
the respose
18. Call it 'mail:' instead of 'mailserver:'. [alternative list]
unacceptable. Already we have mailto: and mid: for different
objects which really are defined in the SMTP model.
Calling something "mail" when it is something kludged on top
of mail is a waste of a good word. It'll also confuse people:
I bet people will use it instead of mailto: accidentally.
19. Identify afs:, mid:, cid:, and other scheme prefixes that have
been mentioned but not specified here. (including tn3270, rlogin
if not reinstated). [really a style issue]
preferable. Makes document more readble.
20. Put back in `tn3270' URLs in this document. [taken out without
clear sense of consensus]
preferable. It was put in on user request
21. Put back in `rlogin:' URLs in this document. [ditto]
preferable. ditto.
22. Remove "#" as a character that is universally reserved, and
instead only reserve it in http, ftp, gopher, news. [universially
reserved without much discussion]
unacceptable. Reserved set must be protocol independent as above.
Tim