Re: Use of ";" in relative URLs: procedural issue?

"Karen R. Sollins" <sollins@lcs.mit.edu> Mon, 03 February 1997 21:59 UTC

Received: from cnri by ietf.org id aa10405; 3 Feb 97 16:59 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa23567; 3 Feb 97 16:59 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA16718 for uri-out; Mon, 3 Feb 1997 16:10:02 -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 QAA16707 for <uri@services.bunyip.com>; Mon, 3 Feb 1997 16:10:00 -0500
Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18747 (mail destined for uri@services.bunyip.com); Mon, 3 Feb 97 16:09:58 -0500
Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id QAA11993; Mon, 3 Feb 1997 16:09:42 -0500
Date: Mon, 03 Feb 1997 16:09:42 -0500
Message-Id: <199702032109.QAA11993@lysithea.lcs.mit.edu>
From: "Karen R. Sollins" <sollins@lcs.mit.edu>
To: masinter@parc.xerox.com
Cc: uri@bunyip.com
In-Reply-To: <97Feb3.082628pdt."241"@palimpsest.parc.xerox.com> (message from Larry Masinter on Mon, 3 Feb 1997 07:26:28 PST)
Subject: Re: Use of ";" in relative URLs: procedural issue?
Sender: owner-uri@bunyip.com
Precedence: bulk

   From: Larry Masinter <masinter@parc.xerox.com>
   Date: Mon, 3 Feb 1997 07:26:28 PST
   Sender: owner-uri@bunyip.com
   Precedence: bulk

   There is a proposal to change the definition of relative URL
   processing from that previously defined in RFC 1808 and
   draft-fielding-url-syntax around processing of relative URLs that
   start with semicolons:

   > Semicolons were introduced to allow elements to be specified by name
   > rather than position, for spaces which were best seen as matrices
   > rather than trees.  In this case it is only sensible for relative
   > URls which start with ";" to take a set of attribute values which
   > are different.  This implies

   >  1. attributes can only occur once (unless you have a syntax for
   >     removing a particular occurrence) and
   >  2. a missed value is equivalent to an unspecified value (so you can
   >     remove an occurrence by setting its value to empty)
   >  3. attributes are unordered

   This is quite attractive, and is important for some schemes.  No one
   seems to implement this currently, though, so introducing it at this
   point seems like we would at least have to start over at "Proposed
   Standard", and should only do so if the consensus of the community is
   that this is the right thing to do.

   So, do you think this is the right thing to do?

   Larry


Let me suggest that if you really want to support unordered attribute
sets as names that you look VERY carefully at why this approach was
dropped by the CCITT a number of years ago.  Instead they brought us
X.500, which is ordered attributes.  For a variety of reasons they
decided that unordered ones were unimplementable in any efficient way,
so you should make the case that their arguments are no longer valid,
before jumping off this particular cliff.

I've always liked the idea, but I've never been convinced that we
could overcome the impracticality of it.

			Karen