Re: Representation of OIDs as URIs

Hello Karl,

Many thanks for your message. The best mailing list for this
discussion is uri@w3.org, where you will find the experts and
interested people. If you are (an employee of) a W3C member
organization, you may also be interested in the W3C URI Planning
Interest Group (see http://www.w3.org/Addressing/Activity#current).

Regards,   Martin.

At 00/11/24 10:29 +0100, Karl Scheibelhofer wrote:
>in the last ETSI ESI meeting we discussed how we could represent OID (ASN.1)
>as URIs. i proposed two schemes that seem reasonable. we would also like to
>hear other opinions.
>these two approaches are as follows:
>
>One encodes the OID as an URL and the other encodes it as an URN:
>
>$B%-(B       Encoding as URL:
>fix a base URL and append the OID in an appropriate format (human readable)
>e.g.,
>http://www.etsi.org/oid/itu-t(0)/identified-organization(4)/etsi(0)/electron
>ic-signature-standard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1)
>The generated URL must be persistent! This means that the resulting URL must
>not be used to identify anything else than this OID. And this should be the
>case, at least as long as this URL is used to identify this OID.
>Advantages and disadvantages of this approach that we are aware of by now,
>are as follows.
>Advantages:
>+       Uses the widely know schema of URLs.
>+       The owner of the OID can place a specification document at the 
>place on
>his web server this URL refers to.
>+       If there is no resource (e.g. a specification) at the given URL, 
>then it
>is just a unique name like an OID is.
>+       Every company can use its own base URL. Some people also mentioned the
>idea to use one base URL for all OIDs (e.g. http://www.w3.org/oid/,
>http://www.oid.int or http://www.iso.org/oid). This would have the advantage
>to have always the same base URL. The disadvantages would be: If the owners
>want to place a specification on the web server, the owning company would
>have to maintain web space for all OID owners (perhaps a redirection
>mechanism would solve this?). Additionally, if a company wants to use this
>base URL for internal (or even secret) purposes, it might not want to use
>the fixed base URL (perhaps, it could just use anyone, if it is just for
>internal use?)
>Disadvantages:
>-       The company owning the domain name of the base URL must ensure 
>that the
>base URL is persistent. It needs to be persistent as long as there is one or
>more URLs in use for identifying an OID using this base URL. Remind that the
>base URL includes the domain name and any additional directories.
>-       If the URL is used just as a unique name without referring to any
>resource, it might confuse people.
>
>$B%-(B       Encoding as URN:
>register a NID (see RFC 2141 and RFC 2611) through IANA
>(http://www.iana.org)
>e.g., register $BEP(Bid$BG(Bas an NID, define NSS to identify an ASN.1 OID. This
>could look like
>urn:oid:itu-t(0)/identified-organization(4)/etsi(0)/electronic-signature-sta
>ndard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1)
>for instance.
>Advantages and disadvantages of this approach are:
>Advantages:
>+       There is a central registration authority for NID.
>+       This approach could serve for all OIDs automatically (e.g. if the
>registered NID would be $BEP(Bid$BG
(B.
>+       IANA guarantees that NID are registered only once.
>Disadvantages:
>-       This mechanism of URNs with registered NIDs seems to be rarely 
>used. Some
>people might reject it just because they are not familiar with that kind of
>URI.
>-       There is no widely used and globally available mechanism to 
>dereference an
>URN. Thus, it might not be possible to retrieve a specification with the
>given URN as seen with the approach using URLs.
>At first glance, the approach using a URN seems to have the advantage to
>guarantee uniqueness. But there is never a hundred percent guarantee for
>uniqueness of any data. It is simply impossible. No one can securely prevent
>me using any identifier the I want. In both approaches, the owner of the
>base URL or of the registered NID has to ensure some properties.
>Just consider the case in which a company is sold. If the succeeding owner
>decides to change the rules and reassign all previously used identifiers,
>the system does not work, no matter what scheme you use: URNs, URLs, or even
>OIDs. Any of these systems only works, if everyone stick to the rules.
>
>
>what do you think is the preferable approach?
>
>
>   Karl Scheibelhofer
>
>--
>
>Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iaik.at>
>Institute for Applied Information Processing and Communications (IAIK)
>at Technical University of Graz, Austria, http://www.iaik.at
>Phone: (+43) (316) 873-5540

Received on Friday, 24 November 2000 13:00:20 UTC