Subject: OIDs as URI/URNs....

From: Michael Mealling <[email-masked]>
Date: Mon, 27 Nov 2000 11:26:04 -0500

Hi everyone,
  I'm crossposting this between the URN Working Group and the XMLDSIG
Working group. The issue is whether or not the OID URN namespace
document that is the process of being published should be ammended
to include the textual representation of the node in the OID tree.

the issue is whether the OID URN NID should look like this:
urn:oid:itu-t(0)/identified-organization(4)/etsi(0)/electronic-signature-sta
ndard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1)

(note, the slashes would have to be changed or encoded since slashes
are deprecated in URNs due to hierarchy semantics in RFC 2396)

or like this:

urn:oid:0.4.0.1733.1.4.1

XMLDSIG apparently has some requirements for readability that is considered
dangerous for the persistence requirements for URNs. Should I update
the pending RFC 3001 and resubmit or should it go forward as is?

-MM

----- Forwarded message from Karl Scheibelhofer <[email-masked]> -----

From: "Karl Scheibelhofer" <[email-masked]>
To: <[email-masked]>
Subject: RE: OIDs as URIs
Date: Mon, 27 Nov 2000 16:58:28 +0100
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[email-masked]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

> Hmm...interesting. URNs have the soft requirement of not being
> human readable.
> Where is the expection coming from for a user seeing and needing to
> understand an OID?

the main purpose for use to use OIDs in URIs is in XML signatures. there we
will need to use OIDs in form of URIs to refer to policies, other documents,
... that are already present and hav an OID. because XML has the great
advantage that it is plain text, it can be read (debugged) by humans by just
viewing it with any text editor. URIs are normally in form that you can
roughly get an idea what's behind it. if we just use the pure number
presentation of OIDs, i think (and others share this opinion) we are going
to lose one advantage.
however, i am aware of the fact that it is not absolutely required to work.
but it was a requirement in designing XML "XML documents should be
human-legible and reasonably clear". i think a pure number presentation of
OIDs does not meet this requirements.

best regards

  Karl Scheibelhofer

--

Karl Scheibelhofer, <mailto:[email-masked]>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) (316) 873-5540

----- End forwarded message -----

--
--------------------------------------------------------------------------------
Michael Mealling        |      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions       |          www.lp.org          |  [email-masked]

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 27 Nov 2000 12:45:16 -0500

(I'm not cross-posting, 'cause <your> listserv stripped the
XMLDSIG list address cc: off your posting, and I don't know what
it is :-)

I'd have some concern about:  what happens when there is discrepancy
between the digit and textual representations (i.e., it's an
error).

I'm not entirely sure that the XML problem couldn't be solved by
a convention of a comment line that accompanies any identifier,
to spell out what they need.

But, that's fairly top-of-my-head.

Leslie.

--

-------------------------------------------------------------------
"Days used to be longer."
   -- ThinkingCat

Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Mon, 27 Nov 2000 10:13:41 -0800

> between the digit and textual representations (i.e., it's an

For normal OID's this is well defined- the numbered form takes
precendence, always (and is usually mandatory to show).

Dw

---

From: Michael Mealling <[email-masked]>
Date: Mon, 27 Nov 2000 14:32:13 -0500

> precendence, always (and is usually mandatory to show).

So what should the OID URN contain? Should it contain all of it and
just have the syntactic equivalence rule in the NID spec say that
only the number counts? While that's technically possible it just
seems like it would create no end of problems and confusion for
when someone decides to use 'em or not or they get the text part wrong.

-MM

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Nov 2000 18:04:31 -0500

I deeply dislike the verbose form. If is is supported it should be a
separate option for use in cases where verbosity is required.

As a practical matter it is highly undesirable to require the verbose form.
In many cases an application will not know what the text tags are for the
OID segments in any case. Applications are very likely to end up with
different text tags. I am not aware of any particular care being taken to
ensure that the OID arcs are consistently named. I have certainly submitted
draft RFCs that have renamed arc segments in all manner of devious ways.

In ASN.1 the match is performed on the bits on the wire. The URN should not
include additional information.

My interpretation of the XML approach to verbosity is that it does not
attempt to reduce verbosity but it does not insist upon unnecessary
verbosity either. In most cases the OID will be followed by a large blob of
BASE64 encoded CDATA.

The proposal will do nothing for readability and introduce nummerous new
sources of error.

        Phill