Re: Uniform Resource Names - almost draft

[Martin Hamilton <[e-mail]>]

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