To: masinter@parc.xerox.com
Subject: Re: questions on URL draft
Date: Sun, 17 Jul 1994 21:35:21 -0400
From: John Curran <jcurran@nic.near.net>
Message-Id: <9407172136.aa08924@nic.near.net>
Larry,
Sorry for missing the survey... I've been out for the last
week or so. Here's my views if you think they're still relevant:
] 1. Add ">" to the list of characters that are `universally reserved'
] and must be encoded in all URLs). [Used for terminating <>]
Yes.
] 2. Add "<", ">", and """ (doublequote) to the list of characters
] that are universally reserved. [as with 1, but be safe]
Mumble. These are unsafe by context; are you trying to eliminate that?
] 3. Remove `wais:' scheme from this draft. [not well enough defined?]
Abstain. (I would prefer that we ask FreeWAIS/WAIS,Inc. their thoughts.)
] 4. Add `local-file:<path>' as a URL that references a local file.
] [one opinion]
No. This is not necessary, "file:" is sufficient.
] 5. Add `file:<path>' as a URL that references a local file. [closer
] to current practice]
No. See 6.
] 6. Add `file://<host>/<path>' as a URL that references a local file
] when referenced from <host>. [as per TimBL]
Yep.
] 7. Include `file://localhost/<path>' in file URLs. [as per TimBL]
No. Use form #6 above.
] 8. Add `&' as a `reserved' character. [used in forms response]
No. Implementation (WWW) specific restriction, I thought...
] 9. Add `&' as a `reserved' character, and describe its use in the
] URLs that result from encoding the value of HTML forms. [more
] writing]
No.
] 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]
While the gateway shouldn't be looking inside the URL,
"be strict in what you send" would advocate a finite list
of reserved characters.
Yes.
] 11. Add an Appendix B that describes `relative URLs' in this document.
Sure.
] 12. Move the "URL:" prefix requirement to the (first) Appendix as a
] recommendation for URLs `in plain text'.
Yep.
] 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]
Yes! Despite everything we say, the user comes first.
] 14. Limit `scheme' names to lowercase ASCII letters, digits, plus,
] hyphen and underscore, with no encoding. [as proposed]
Yep.
] 15. Remove the recommendation for using "x-" scheme names. [as proposed]
]
Keep in. I'd like to know there's an RFC for a non "x-" scheme.
] 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]
No opinion. It's not similiar to other URL's in function,
so I'd need to understand the value before taking a stand.
] 18. Call it 'mail:' instead of 'mailserver:'. [alternative list]
See 17.
] 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]
Mumble. Do we really want to encourage scheme-of-the-month-club?
No opinion.
] 20. Put back in `tn3270' URLs in this document. [taken out without
] clear sense of consensus]
Sure. Include a spec for how it's interpeted.
] 21. Put back in `rlogin:' URLs in this document. [ditto]
Sure. Include a spec for how it's interpeted.
] 22. Remove "#" as a character that is universally reserved, and
] instead only reserve it in http, ftp, gopher, news. [universially
] reserved without much discussion]
We really need to decide whether the character sets are URL
specific. Everytime we add something (like # or &) we are
potentially causing a great deal of code to have to change.
I don't mind have a reserved set (including # and/or &), but
I do not agree that we can have a common interpetation as to
the semantics across URLs... #anchor simply isn't meaningful
in some schemes, so the question is whether they can reuse #
to some other interpetation.
btw, the last survey on a working document that I took which was
in this format (vote on each item, yea/nea, etc.) was a Fortran
standard ballot... I'm not sure that's a good sign.
/John