Re: composition of Issuer identifier (also: "dns-date" URN NID)

[Jeff Hodges <jhodges@oblix.com>]

Phillip Hallam-Baker wrote:
> [...]
> 2) Where issuer IDs are concerned the 'issuer' is clearly not 'downloadable'
> but there might well be a need at some point to support some form of service
> that was resolved in some fashion from the Issuer ID.
> 
> Here DNS names make a lot of sense since it is possible to map from a DNS
> name to a service of any type using an SRV record. 

Agreed. 


> 3) The DNS-DATE URN scheme has come up many times in many forms. The
> earliest one in actual use being the Presidential Document Identifiers used
> by the Whiethouse Publications service in 1992. 

Well, fwiw, something ~akin~ to "urn:dns-date" may have come up in the past,
but as far as I and google, altavista, & ask-jeeves are concerned, it's only
explicitly been mentioned in the context of our (SSTC) mailing lists and
documents. 


> The observation is that
> ownership of a DNS name can be transfered. Therefore to 'fix' the semantics
> of the name it is necessary to extend the name with the date. ....

Yes, seemingly. BUT, there's tons of issues involved in defining such a
namespace. They've recently been discussed in excruciating detail in the "tag"
URI scheme doc (http://www.taguri.org/) and especially in the LONG thread on
the uri@w3.org mailing list, begining with the msg:
http://lists.w3.org/Archives/Public/uri/2001Apr/0013.html

For example, in said thread, Michael Mealing (of Network Solutions) points
out..

> Speaking semi-authoritatively here: [DNS records are] not kept in any
> consistent way. I think most companies keep their records for a few years 
> as a simple matter of legal prudence. But there is no permanent record of 
> who owned what domain on what date...


So, I really think that the best, most reasonable, widely-understood thing we
can use for an issuer identifier is an otherwise unadorned, "absolute" DNS
domain name (see RFC1034; aka a "Fully-Qualified [DNS] Domain Name", aka a
"FQDN").

And we should conciously realize that doing so will provide implementors and
deployers significant latitude for "tying into other infrastructures". To
borrow from draft-eastlake-uri-fqdn-param-00.txt...
  
   Extensive Domain Name System facilities such as wildcards,
   CNAME, MX [RFC 1035], SRV [RFC 2782], and DNAME [RFC 2672] 
   provide much flexibility in mapping subdomains, services, 
   and hosts to each other. 


JeffH