Outstanding URL issues
This is a a running list of issues
about URLs and about which which
discussion is still running, or recently
closed. These are taken mainly from
summaries on the list by various
people. The order is random. As
they are settled I'll leave them
in as history. See also the change
history .
As editor I am happy with the current
spec except I would like the WG to
check whether the large amounts of
Gopher+ stuff can't be changed to
a reference to some entity in the
Gopher+ spec as we have done for
all other protocols. (see below)
FTP
Transfer mode
How should the transfer mode be encoded
into the URL, if at all? The current
feeling is that it should be optionally
encoded as a suffix by the use of
some delimiter.
Editor suggests the use of "!".
Requires adding this character to
reserved set. This was succeded
by:
Dan Connolly suggests using ";mode=binary".
(Editor points out need to reserve
the ; and = and remebers this must
be done for WAIS anyway. ) Also,
Editor suggests using FTP terminolgy,
";type=i".
Change order of account and password
Alan suggested changing the order
around. The editor rejects this
:-), subject to outcry, on the basis
that:
- This is not the time for incompatibe
changes
- The change is arbitrary
- The order "user@host" has a tradition
long established, and to propose
"host@user" would drive people crazy.
Gopher+ and search strings
Search string terminator
Should the normal URI convention
of using "?" as a sparator for search
strings be changed to HT (horizonatl
tab) in the case of Gopher because
that is how it is represented in
the protocol? This came up from
the extention of gopher to gopher+,
but is in fact orthogonan question.
Should the URN spec just refer to
the Gopher+ spec? See:
Slashes as non-hierarchical delimiter
Should it be strictly enforced that
"/" never appear unencoded unless
of hierarchical significance? Mark
argues no. Others argue yes. Editor
points out that so long as within
Gopherworld noone uses any partial
forms, there is no problem in practice
either way, the difference will not
surface in any code, so its not a
big deal.
Should a prefix "URL:" or equivalent
be considered part of the URL? Should
it be part of a wrapper used when
writing a URL within plain text?
Consesnus declared by the chairman
to be that "URL:" should be a mandatory
part of the specification fothe URL
for use in all cases. Later comments
by the chairman seem to indicate
that it may be optional.
Strongly disliked by the editor as
much as requiring the string "Telephone:"
to be a mandatory part of a telephone
number.
Consenus: It is in, considered part
of the URL.
Plain text wrapper
In this area, questions are,
- Should one define a wrapper to enable
a URL to be spotted within plain
text?
- Should it be part of the URL? ( no
- alan )
- Should it be an appenix item, or
mandatory? (appendix -ed)
- What characters should be used? Consesnus
is "<", ">". Arguments for and against
.
- Should it include or replaced the
prefix mentioned above? (no -ed)
The chairman suggests the answers
are YES, NO, appendix, "<" and ">",
no.
Wrappers in other contexts
Larry Masinter suggested that "the
wrapper be allowed to be any ONE
OF < > or " " or ' ' or { },
to allow the wrapper to be used
effectively in multiple contexts.
This allows maximum flexibility,
some compatibility with SGML (in
HTML, the wrapper would be the ""
or '' in <A HREF="url:...."> )."
Others (I forget who, sorry) had
felt that in other contexts, the
delimiters are defined.
NNTP
- Should a format be allowed to refer
to a news article on a specific local
NNTP server by group and article
number? ( Mitra's argument , TimBL's
argument) (consensus: yes, with warning)
- If so, should the same "news" prefix
be used? (consesnus:no)
- Should "news" be changed to something
else such as "nntp" or "usenet" in
all cases? (Consensus: no)
Tim BL