Re: Representation of OIDs as URIs

Dear all,
Some additional precissions to the message by Karl, coming from
my understanding of what it was said  in the ETSI meeting.

First, it was seen that this is a very generic problem whose solution
should involved to a vast community (even broader than W3C signature
group). So, if you know of relevant people in the W3C that could give their
opinion, you could pass these messages to them, or even you could direct
us to the specific forum (if there is one) where to raise the topic.

Second, although it is true that no decision was taken, the general feeling
of the group was more in favor of the URL solution, but then two different
approaches were sketched concerning to the management of the URLs.
I will try to summarize (please ETSI people, correct me if you think that I
missunderstood
them):

1. Try to envisage the possibility of making alll these URLs to be below of
the umbrela of W3C. So the URLs the could be something like:
http://www.w3.org/etsi/oid.

2. The second alternative would be that ETSI would keep itself as the
base URL: http://www.etsi.org/oid/....

So the questions that remain open are: which is the forum where
this discussion should take place? which one of the schemas proposed
seem to be more convinient? what would be the most convinient way 
for proceeding to the allocation and definition of the URLs (W3C tree or
ETSI tree)?

Regards.

Juan Carlos Cruellas.


At 10:29 AM 11/24/00 +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:
>
>·	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.
>
>·	Encoding as URN:
>register a NID (see RFC 2141 and RFC 2611) through IANA
>(http://www.iana.org)
>e.g., register “oid” as 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 “oid”).
>+	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 05:38:16 UTC