NIC handle writeup

[ Apologies for prematurely pressing send. It's Friday afternoon :-( ]

=> "%" still has mail-related connotations though, although far less so than
=> "@".
=> 
=> How about ":"? JA39:APNIC.NET doesn't look like an e-mail address or a DNS
=> name. It does however look slightly remotely like a URL ;)
=
=	":" not only has URL significance, its also used w/ IPv6 in the
=	address.  IMHO a poor choice.  

  I don't think that we're going to find any character which isn't badly
  overloaded already...

=> Or have I misunderstood the point you were making?
=
=	I think so.  Back up a bit and take the 10,000m view.

  Yup: why do we need a special character at all?

  Grab a handle, which simply must not contain the "." character, 
  and extend that with the DNS-part as proposed. Done. 
  And it is known to work (DNS SOA record)
  
  My good old WW144 would then simply become WW144.INTERNIC.NET.

=	There are three classes of Internet intangibles that 
=	can be delegated, ASN's, Prefixes, Port numbers. (there 
=	are others, but these will do for this purpose)
=
=	The recipiants of these delegations can be people (admin-c/tech-c),
=	hosts (HST), organized groups (mntner & role accounts)

  While this is probably off-topic, I suppose you are mixing organisations
  and contact information here...

=	I could make the case that the mntner:, admin-c:, tech-c:,
=	mnt-by:, nic-hdl:, and the HST (C8-HST) are all, in a very
=	real sense, NIC HANDLEs.  They specify a relationship between
=	Internet resources and those who are authorized to manage the
=	delegation relationship.

  I have to disagree. 

  - We do have mechanisms to describe the privilege(s) for maintaining
    objects.

  - And we do have mechanism to get in touch with persons (or helpdesks or
    NOCs) for operational purposes.

=	Here, I expect that the handle:
=
=	WM110
=	WM110-NSI
=	WM110-ARIN
=
=	all reflect me, first under the SRI-NIC, then Internic/NSI, then
=	ARIN.  I would hope the design of NIC-handles would allow migration
=	of data between registries as well as allow for a deeply nested
=	registration heirarchy.

  What we've learned from past (failed) attempts: 
  - don't try to mix the issue generating globally unique identifiers with
  - the issue of data exchange between registries
  
  As soon as we've sorted out the first one, we can try to work on the
  second one. Having the first one done is not going to interfere with
  solving the other issue, I suppose :-)
  
  Wilfried.
 --------------------------------------------------------------------------
  Wilfried Woeber                :  e-mail: Woeber at CC.UniVie.ac.at
  Computer Center - ACOnet       :  Tel: +43 1 4277 - 140 33
  Vienna University              :  Fax: +43 1 4277 - 9 140
  Universitaetsstrasse 7         :  RIPE-DB (&NIC) Handle: WW144
  A-1010 Vienna, Austria, Europe :  PGP public key ID 0xF0ACB369
 --------------------------------------------------------------------------