Re: Extended URL for frames

Scott E. Preece wrote:
> The proposed approach of using ordered lists of frames seems awfully
> fragile to me.  If the definition of the "master page" changes the
> ordering of frames, any bookmarks for it become garbage.  I'd really
> rather see names used to identify the frames referred to in the
> URL.

My initial argument was that there is no requirement that frames be
named, or that names be distinct. But a frame is typically named if
it's to be updated by anything but a script, so that argument is weak
for a syntax only concerned with updated frames.

So here's a syntax altered to suit your preference:


Frame name and URL are enclosed between '(' and ')' as these
characters are declared legal in fragments. There is no longer a need
for placeholders for unchanged frames. Now the rule is that a '#'
terminates an anchorname/id as well as begins it, and when the
terminating '#' is followed by a left parens '(' it marks the beginning
of a frame id within a fragment. Within each level of frame
information, additional URLs with fragments can be nested. In the above
URL example, 'frame3' at the top level has changed, having been loaded
with f3.html. Within frame3, the nested 'frame3-2' has also changed,
having been loaded with f3-2.html. Note that f3-2.html has a fragment
identifier for a named anchor 'there' and that the name is terminated
with a '#' to avoid rules concerning ')' as a fragment terminator.

Are additional '#' characters strictly forbidden in a fragment? In
RFC1808, '#' is classified as 'punctuation', and as such illegal. In
RFC1608, '#' is classified as 'reserved' but the 'fragmentid' is not
allowed to contain reserved characters. Given its restricted usage,
'reserved' seems like a more logical classification for '#' and
'reserved' characters seem reasonable in a fragment. The fragment is
the only client-relevant part of a URL string. It's not sent with the
request string and there's no need for arbitrary restrictions on its

Whatever construct is chosen to represent frames in a URL string (if
any), both browsers and mail readers will have to be taught to
recognize it.


Received on Monday, 16 September 1996 19:31:28 UTC