Message-Id: <9310292333.AA06688@expresso.bunyip.com>
From: Peter Deutsch <peterd@bunyip.com>
Date: Fri, 29 Oct 1993 19:33:51 -0400
In-Reply-To: Mitra's message as of Oct 29, 16:16
To: mitra@path.net (Mitra), marca@ncsa.uiuc.edu
Subject: Re: Single protocol for UR*?
Gad, at this rate I'll never get to the airport!
Anyways, I'll answer a couple of more...
[ Mitra wrote: ]
> 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.
I'm not sure where the hierarchy will be in this, or if we
need, for example, the naming authority to itself be
hierarchial. I _am_ sure that we want the URN: prefix at the
front, for all the reasons people such as John Curran
outlined.
Thus, I'm not sure what we could reverse, here, except
maybe the naming authority and the pubid. This deserves a
bit of thought before we decide...
. . .
> } 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.
Yes, I expect we'll find several nesting in the trees that we
can shake out....
. . .
> } 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. . . .
Answering this will require us to agree on what the
corresponding record should look like. Does each record
contain the naming authority, pubid and id? Does it
contain only a template type plus the entire URN and set
of URLs, as you propose? The query generated will be
determined by the answers to these questions. From what I
see the basic query would need to identify the template
and probably the pubid, plus search on the ID string, but
since all of this is in the URN, we could just search on
the URN and we're done.
Assuming we use your format, the query really is trivial.
For the URN:
URN:ISOC:Deutsch:42
The query would look like:
template=URN; URN=URN:ISOC:Deutsch:42
This will return the record with the matching URN and
you're done.
> . . . If you end up needing all of whois++ (language, and template and
> stuff) then I'm worried.
Well, each record is a template, however you store it so
we need to support that. WHOIS++ has only one search
command format, although it is general and allows you to
search on attribute name, attribute value, combined
attribute/value, template and handle (the unique id for
each record). I don't see any particular value in
hard-coding the template type and so on this early, and
some value in being able to do more general searches (eg.
specify a URL instead, specify different template types as
we go to URCs and so on). I'd suggest that we use the
general structure with an agreed-upon template for now and
see if we suddenly find that we're missing a couple of
vital attributes, or whatever.
> } 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. . .
>
> 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.
The idea behind including a standard token for each
attribute is that smart clients can do a better job of
local language customization without further help from the
server and servers can do what they do best, which is
proces queries, not worry about display issues.
Again, this is not essential for the architecture debate,
but I do think tokenizing is a better approach than the
huge, structured data element names I've seen so far in the
"non--existant Data Elements Working Group document",
which is the alleged output of the "non--existant Data
Elements Working Group". :-)
> } Actually, I'm not proposing we hold things up on this, I
> } just tossed it out as a stream-of-consciousness idea.
. . .
> Great - punt it to the non-existant Data Elements Working Group :-)
Exactly. I love delegating... :-)
- peterd
-- ----------------------------------------------------------------------Actually, folks who spend their spare time sitting glued to a glass box, hitting a space bar, are rarely the movers and shakers of the universe;
From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) ----------------------------------------------------------------------