From: mitra@path.net (Mitra)
Date: Fri, 29 Oct 1993 16:16:48 PDT
In-Reply-To: Peter Deutsch <peterd@bunyip.com>
To: peterd@bunyip.com, marca@ncsa.uiuc.edu
Subject: Re: Single protocol for UR*?
Message-Id: <9310291616.aa24059@pandora.sf.ca.us>
On Oct 29, 3:27pm, Peter Deutsch wrote:
} Something about fanouts of thousands.
If the namespace is hierarchical, we could just reverse it and replace
slash with . (and what to replace . with), maybe we could make that
entire field be in reverse order with .'s in it instead of slashes or
colons.
} > } The following looks pretty good to me, although I'd add
} > } one more step to separate the naming authority server from
} > } the specific pubid server (I'm sure ISOC doesn't want to
} > } run a service for every member, although they might be
} > } willing to run a server pointing to each member's server).
} >
} > Sounds good, in which case modify it to look up "pubid.anamespace.urn"
} > in the DNS, standard DNS mechanisms already handle decentralising that.
}
} I'd have to ask a DNS guru how this approach would scale
} if the naming authority has to list thousands of entries?
} After all, I suspect that the fanout might exceed anything
} we currently see with existing practice. Still, if nobody
} sees a problem, this approach means that it can be brought
} up real fast once the powers-that-be agree to the new top
} level domain and we find someone to operate the top level
} servers.
}
} I _am_ still wondering if we shouldn't have the top level
} be ".uri", with the "urn" one level down, to avoid a
} plethora of new top level domains. Maybe we even want a
} ".service" domain, with "urn.server"? We do need input from
} the DNS community here.
And where better than IETF-Houston to get it, if we are clear we want
something like this, I dont care what string I append to it.
}
} > Not even that Peter, it requires acceptance of a specific subset of
} > Whois++ to achieve a few very limited tasks. If the server provides
} > other features of whois++ that is an advantage, but we dont have to
} > agree on that in order for this scheme to work.
}
} I addressed this concern in an earlier posting, but I'll
} repeat - I'm not sure how we'd use a "subset" of WHOIS++,
} since the protocol is pretty minimalist now. Suggestions
} for specific commands that could be omitted??
} There's really not that much to chop...
Peter - we are still waiting (among thousands of peices of mail today
:-) for your outline of what simple queries might be required to resolve
a URN. If you end up needing all of whois++ (language, and template and
stuff) then I'm worried.
}
} I'd have to disagree here. If I'd like to find all author
} names, it would be nice to look for "token 10", not
} "author, auteur, whatever_it_is_in_German" and so on. More
} importantly, it recognizes that there are lots of people
} coming onto the net in the next couple of years for whom
} English is not in the default language set.
I'd assume its easier to use the English (standard) version as the
token, i.e. all protocol queries in that language. Results (for the tag)
returned in either US.English or (if the server supports it) a
language specified in the query. Translation to the user's language by
the client. After all, the client typically is putting this information
in a form anyway if its going to a user.
}
} Actually, I'm not proposing we hold things up on this, I
} just tossed it out as a stream-of-consciousness idea.
} Still, I do hope that we don't ignore the issue as we
} progress, although I recognize that it's really a data
} elements issue and doesn't have to be solved for the rest
} of this stuff to work (nor do I have any idea where they
} data element SWAT team is on this topic right now, since
} they've been pretty silent of late. I suspect they're all
} up to something, but Alan wont tell me what! ;-)
}
Great - punt it to the non-existant Data Elements Working Group :-)
- Mitra