Message-Id: <9307261139.AA04313@xdm039>
To: uri@bunyip.com
Subject: Fragment-id in the URL RFC
Date: Mon, 26 Jul 93 12:39:24 BST
From: "Peter Lister, Cranfield Computer Centre" <P.LISTER@mail.cranfield.ac.uk>
Tim,
First of all, what is "an object or object" under fragment-id at the
top of page 7? Typo, or deeply significant?
I don't agree that a null frag-id (e.g. just a #) is equivalent to no
frag-id. In the case of HTTP, the frag-id is never sent by the client,
but that is a property of HTTP, not of the URL. By all means state that
null is equivalent to "no-frag" in HTTP, but not generally.
In other circumstances, a null frag-id could usefully be valid, e.g. to
direct a client to start displaying the contents of a file at a default
point other than the start (warping straight to the text of an email or
news article, ignoring headers, springs to mind).
Also, I can see circumstances in which a frag-id could usefully be
transmitted to a server (e.g. an ftp server URL pointing to a tar
archive could have a frag-id indicating a particular file stored in it).
Finally, the behaviour as described is different from the query, where
nulls ARE significant, and that just offends me. :-)
If the frag-id (following a #) is explicitly understood to be generic
to all URLs, as the RFC states, then why is the '?' query form
explicitly described separately for each URL type? I appreciate the
some contexts may explicitly not have a searchable context (e.g.
waisdoc), but surely it is also true that some docs can't be fragmented
either, even though specifying a frag-id is legal for all URLs. If it's
because clients are assumed never to transmit a frag-id to a server,
this appears to be HTTPism affecting URLs in general.
Am I making sense?
Peter Lister p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology, Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL England Fax: +44 234 750875