Re: Use of ";" in relative URLs: a way out?

Larry Masinter <masinter@parc.xerox.com> Wed, 12 February 1997 03:12 UTC

Received: from cnri by ietf.org id aa09366; 11 Feb 97 22:12 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa27763; 11 Feb 97 22:12 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA05646 for uri-out; Tue, 11 Feb 1997 21:54:00 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA05641 for <uri@services.bunyip.com>; Tue, 11 Feb 1997 21:53:52 -0500
Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15625 (mail destined for uri@services.bunyip.com); Tue, 11 Feb 97 21:53:49 -0500
Received: from silvery ([13.1.100.64]) by alpha.xerox.com with SMTP id <15135(3)>; Tue, 11 Feb 1997 18:53:46 PST
Message-Id: <330130A1.7477@parc.xerox.com>
Date: Tue, 11 Feb 1997 18:53:21 -0800
From: Larry Masinter <masinter@parc.xerox.com>
Organization: Xerox PARC
X-Mailer: Mozilla 3.0 (WinNT; I)
Mime-Version: 1.0
To: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
Cc: uri@bunyip.com
Subject: Re: Use of ";" in relative URLs: a way out?
References: <Pine.SUN.3.95q.970210154838.245d-100000@enoshima>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-uri@bunyip.com
Precedence: bulk

Martin J. Duerst wrote:
...
> Scaling doesn't have to be that much of an issue because it is not
> the responsibility of the generic syntax to decide whether it can
> be solved in a particular case or not. The main question is whether
> there are cases that can deal with the scaling and where it makes
> sense to have attributes unordered, and whether these cases are
> frequent enough or important enough, and/or don't admit a reasonable
> alternative without unordered attributes to justify adding/keeping
> the unordered attributes in the generic syntax.

I think we've established a long-term design goal that the relative/base
calculation should be uniform and not depend on the scheme at all.
So, you're wrong. It _is_ the responsibility of the generic
syntax to either allow for unordered attributes or not.

I don't understand the 'scaling' issue, though. It is a bit
more code in the relative URL calculation: lots more than the
simple string hacking that is possible now. The cost/benefit
is hard to judge, and there are arguments on both sides.

Another way to handle it would not to require the relative
URL calculation to actually remove duplicates.

If the relative URL starts with a ";" the result could be
merely to append the attributes to the existing URL without
removing any other existing attributes. It is then up to the
individual scheme to decide that duplicates should be eliminated.

E.g., a base

imap://hostport/folderpath/uid=message;section=1.2

conjoined with a relative URL
";section=1.3"

results in a URL of

imap://hostport/folderpath/uid=message;section=1.2;section=1.3

which the IMAP scheme defines to be equivalent to

imap://hostport/folderpath/uid=message;section=1.2;section=1.3

so that the generic syntax doesn't say anything about whether
the attributes are ordered or unordered.