- From: Karen R. Sollins <sollins@lcs.mit.edu>
- Date: Wed, 5 Feb 1997 12:34:22 -0500
- To: masinter@parc.xerox.com
- Cc: uri@bunyip.com
CC: uri@bunyip.com Sender: Larry Masinter <masinter@parc.xerox.com> From: Larry Masinter <masinter@parc.xerox.com> Date: Mon, 3 Feb 1997 18:19:52 PST x.500 doesn't have the equivalent of "relative URLs", does it? I think this is a separate issue from unordered vs. ordered attributes. X.500 only supports them ordered, although I believe it permits wildcards or queries for elements in a path, leading to searches. In other words, if a name is {country=us, state=ma, org=mit, dept=?, person=sollins) it would search all the departments for "person=sollins". Even this level of flexibility may not scale or generalize well (i.e. think about what would happen if there were several "?" in this list), and its been long enough that I'd have to go back and check on even this level of detail. But, originally, before there was x.500, but only proposals, the leading candidate was for unordered attributes of this sort. It simply doesn't scale at all, unless you know some algorithm that I don't. But, since we are talking about URLs perhaps we should be talking about X.400, not X.500 anyway, and I don't know the history there. It also does NOT support unordered attributes, and the syntax is also ordered attributes as with X.500. (But, it is worth noting that the syntaxes are NOT identical; they are specified separately.) Now, I am not one to suggest that CCITT and ISO should be our role models, but we should learn from their experiences where we can. If you are thinking of using unordered attributes somehow only limited to relative URLs, since their scope can also be very large (I don't see any particular limitation on them), scaling must be an issue for them as well. But, as I said, perhaps I missed something here and there are new ways to deal with the scaling problem that have just passed me by. Karen
Received on Wednesday, 5 February 1997 12:34:39 UTC