# Re: questions on URL draft

John Curran (jcurran@nic.near.net)
Sun, 17 Jul 1994 21:35:21 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: pays@faugeres.inria.fr: "Re: New URC Specification is ready...."
- Previous message: pays@faugeres.inria.fr: "Re: New URC Specification is ready...."
- Maybe in reply to: Larry Masinter: "questions on URL draft"

    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

- Next message: pays@faugeres.inria.fr: "Re: New URC Specification is ready...."
- Previous message: pays@faugeres.inria.fr: "Re: New URC Specification is ready...."
- Maybe in reply to: Larry Masinter: "questions on URL draft"