Message-Id: <199410131124.MAA10295@lust.mrrl.lut.ac.uk>
To: paf@nada.kth.se (Patrik Faltstrom)
Subject: Re: Uniform Resource Names - almost draft
In-Reply-To: Your message of "Thu, 13 Oct 1994 07:10:21 BST."
<aac27ee904021004a02d@[130.237.222.114]>
Date: Thu, 13 Oct 1994 12:24:56 +0100
From: Martin Hamilton <martin@mrrl.lut.ac.uk>
Patrik Faltstrom writes:
| There is some syntactic things here which is wrong according to the
| whois++ spec, the query:
|
| !urn:iana:rfc:822
|
| First of all, the shortwriting '!' has been removed from the whois++
| vocabulary, so it is not accepted anymore. You must explicitly
| write out the word "handle=".
I was going by draft-ietf-wnils-whois-arch-01.txt, which
says (p.17):
Valid specifiers:
-----------------
Name Functionality
---- -------------
ATTRIBUTE-VALUE [ ',' <constrnt>]* allows combining attribute and
value specifiers in one term.
HANDLE [ ',' <constrnt>]* Confine search to handles.
SEARCH-ALL [ ',' <constrnt>]* Search everything.
TEMPLATE [ ',' <constrnt>]* Confine search to template names.
VALUE [ ',' <constrnt>]* Confine search to attribute values.
This is the default.
(Note: The name HANDLE can be replaced with the shortname '!')
Is there a more recent version of the spec ?
| Also, the character ':' is in Whois++ a delimiter between the
| search values and the global constraints, such as "hold" which
| is used for holding a connection, or "search=regexp" which is
| made to specify search with regular expressions.
|
| According to the spec, the search should be:
|
| handle=urn\:iana\:rfc\:822
|
| or
|
| handle="urn:iana:rfc:822"
|
| i.e. you must quote the ':'.
OK, you got me there :-)
But what do you think about this idea of differentiating between
URN lookups and searches ? Since bare bones URN lookups probably
don't want to cary the same overheads as searches, it would be
useful to be able to make the distinction
Perhaps the 'handle' specifier isn't the best way to write URN
lookups in whois++ requests, but I think 'urn="<blah>"' and
'template=urn;urn="<blah>"' want to be searches, since they may
result in more than one URC being returned... Any thoughts ?
So, my minimal URN lookup scenario (via 'handle') right now
would be something like this...
success:
% 220-whois++ server cuppat, LUT mini_whois++ 1.0
% 220-only understands handle and urn lookups!!
% 220 your mileage may vary
handle="urn:iana:rfc:1490"
% 200 command ok
# FULL 1
# URN cuppat:rfc1490
URN:IANA:rfc:1490
URL:ftp://ds.internic.net/rfc/rfc1490.txt
URL:ftp://nis.nsf.net/internet/documents/rfc/rfc1490.txt
URL:ftp://nisc.jvnc.net/RFC1490.TXT.1
URL:ftp://ftp.isi.edu/in-notes/rfc1490.txt
URL:ftp://wuarchive.wustl.edu/info/rfc/rfc1490.txt.Z
URL:ftp://src.doc.ic.ac.uk/rfc/rfc1490.txt.Z
URL:ftp://ftp.concert.net/rfc/rfc1490.txt
URL:ftp://ftp.sesqui.net/pub/rfc/rfc1490.txt
# END
% 226 transfer complete
% 203 toodle pip
failure:
% 220-whois++ server cuppat, LUT mini_whois++ 1.0
% 220-only understands handle and urn lookups!!
% 220 your mileage may vary
handle="urn:iana:rfc:1490"
% 200 command ok
# FULL 0
# END
% 226 transfer complete
% 203 toodle pip
couldn't decipher request:
% 220-whois++ server cuppat, LUT mini_whois++ 1.0
% 220-only understands handle and urn lookups!!
% 220 your mileage may vary
handle="urn:iana:rfc:1490";asdfadfasdf
% 502 you what, mate?
# FULL 0
# END
% 226 transfer complete
% 203 toodle pip
This is without SERVERS-TO-ASK. I don't think servers should
respond with SERVERS-TO-ASK unless they want to, but perhaps
someone will convince me of the need for it... ?
Cheerio,
Martin