Date: Tue, 12 Jul 1994 17:24:50 -700 (PST)
From: Mitra <mitra@pandora.sf.ca.us>
Subject: Re: questions on URL draft
To: uri@bunyip.com
Message-Id: <Pine.3.89.9407121718.C21829-0100000@pandora.sf.ca.us>
Firstly - I'd echo what Daniel said about reserved and unsafe, and
suggest an added (short) section listing characters it is recommended
(but not required) to encode because they may be corrupted by brain-dead
transports.
Subject: 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 <>]
preferable
>2. Add "<", ">", and """ (doublequote) to the list of characters
> that are universally reserved. [as with 1, but be safe]
accepatable (barely) why make characters reservered that are only
unsafe.
>3. Remove `wais:' scheme from this draft. [not well enough defined?]
unacceptable - but I could be convinced otherwise, I thought it was well
defined - we received a definition from everyone involved I though?
>4. Add `local-file:<path>' as a URL that references a local file.
> [one opinion]
unacceptable - this makes the reference illegal when moved to a different
system.
>5. Add `file:<path>' as a URL that references a local file. [closer
> to current practice]
unacceptable - see 4.
>6. Add `file://<host>/<path>' as a URL that references a local file
> when referenced from <host>. [as per TimBL]
preferred - if this doesnt exist we'd have to invent it anyway, since we
send these around in email all the time.
>7. Include `file://localhost/<path>' in file URLs. [as per TimBL]
no opinion
>8. Add `&' as a `reserved' character. [used in forms response]
unacceptable - this is internal to www
>
>9. Add `&' as a `reserved' character, and describe its use in the
> URLs that result from encoding the value of HTML forms. [more
> writing]
Dont understand?
>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]
unacceptable: The gateway shouldnt be looking inside the opaque URL
unless it knows the syntax - in which case it can vary from scheme to scheme.
>11. Add an Appendix B that describes `relative URLs' in this document.
preferred - people will use these anyway, better that they be standardised
>12. Move the "URL:" prefix requirement to the (first) Appendix as a
> recommendation for URLs `in plain text'.
preferred
>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]
preferred
>
>14. Limit `scheme' names to lowercase ASCII letters, digits, plus,
> hyphen and underscore, with no encoding. [as proposed]
preferred
>15. Remove the recommendation for using "x-" scheme names. [as proposed]
disliked: It means we never know if a new scheme is the standardised
form, or some pre-standardisation experiment.
>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]
incomplete proposal - no opinion
>18. Call it 'mail:' instead of 'mailserver:'. [alternative list]
ditto
>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]
no opinion
>20. Put back in `tn3270' URLs in this document. [taken out without
> clear sense of consensus]
no opinion
>21. Put back in `rlogin:' URLs in this document. [ditto]
preferred
>22. Remove "#" as a character that is universally reserved, and
> instead only reserve it in http, ftp, gopher, news. [universially
> reserved without much discussion]
huh? Since when was "#" reserved in ftp, gopher or news - did I miss
something?
- Mitra