[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Message Service Specification Version 0.91
Attached are welcome clarifications on URNs and OIDs from Michael Mealling, of Network Solutions. William J. Kammerer FORESIGHT Corp. 4950 Blazer Memorial Pkwy. Dublin, OH USA 43017-3305 +1 614 791-1600 Visit FORESIGHT Corp. at http://www.foresightcorp.com/ "Commerce for a New World"
- From: Michael Mealling <michael@bailey.dscga.com>
- To: "William J. Kammerer" <wkammerer@foresightcorp.com>
- Date: Thu, 4 Jan 2001 08:04:37 -0500
On Wed, Jan 03, 2001 at 07:39:30PM -0500, William J. Kammerer wrote: > We've gone around in circles with this before, but we'll either have to > use a URL (which could change at any time, as URLs are wont to do; e.g., > yesterday http://www.delta.com/ belonged to a poacher, and you had to > use http://www.delta-air.com/. Then they got http://www.delta.com/), > or this thing called a URN. But there are no URNs defined, except for > ONE lone namespace for the IETF - see > ftp://ftp.isi.edu/in-notes/iana/assignments/urn-namespaces. So when is > Dun & Bradstreet going to rush out and register themselves a URN > namespace? Don't hold your breath; in the meantime, RosettaNet and > BizTalk are identifying the sender and receiver by D-U-N-S number. One of the main reasons that you haven't seen any new ones is that the registration process has only been in place officially for the past year. There have been several (10 or so) proposals that are all currently working thier way through the process. Here is a small list: OID -- Object Identifier ala ASN.1 PIN -- A Verisign mantained namespace for people and organizations xmlorg -- recently requested for OASIS oasis -- also requested by OASIS isbn -- requested by the ISBN maintenance agency iana -- being developed as a namespace for all IANA registered protocol elements > The second URN namespace might be for ITU-T Rec. X.660 (ISO/IEC 9834-1) > object identifiers; see OID URN namespace...., at > http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0455.html, which > refers to a draft of "A URN Namespace of Object Identifiers," by M. > Mealling, the newest copy at ftp://ftp.isi.edu/in-notes/rfc3001.txt. Which has been published as RFC 3001. Due to a snafu its being republished but the namespace will be registered as is.... > If an OID points directly to a company, as in the case of the private > enterprise numbers referred to in Mealling's e-mail, then that may be an > adequate and unique PartyId, which is well-known and uniform enough to > be signed in a certificate extension (so that you know who is purporting > to be so-and-so, really is). So > <PartyId>urn:oid:1.3.6.1.4.1.6255</PartyId> really does uniquely point > to Commerce One (at least after the oid namespace is allocated). This > is all fine and good, and you can even do addressing by D-U-N-S, as in > > <PartyId>urn:oid:1.3.6.1.4.1.519.1.782501225</PartyId>, > > which uniquely points to FORESIGHT Corp., using FORESIGHT's D-U-N-S > number. Alternatively, I could be found via the ISO 6523 ICD (0060) for > Dun and Bradstreet: > > <PartyId>urn:oid:1.3.60.782501225</PartyId> All of this is very accurate, yes.... > A problem arises when I want to define the naming authority via an OID, > but want to refer to the ultimate ID within the <PartyId> element data, > as in the case when the ID contains alpha characters which are not > allowed in an ASN.1 OID (e.g., a four character alpha SCAC, a Canadian > Tax ID, or a SWIFT BIC). Then I would want to use the "type" attribute > to specify the URN for the naming authority OID, as in > > <PartyId type="urn:oid:1.3.21">BONEUS33XXX</PartyId> > > which points uniquely to BANK ONE COLUMBUS,N.A. via the SWIFT BIC, > registered as ICD 0021 with the BSI which maintains ISO 6523; see > http://www.alvestrand.no/objectid/1.3.html. This is one method. The other method is to create a namespace that grandfathers in all of the namespaces you are attempting to use here. I'm not personally knowledgable about SCACs or SWIFT BICs (a lighter?) but as long as they are unique and non-reassignable you can create a URN namespace out of them with little effort.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com
- From: Michael Mealling <michael@bailey.dscga.com>
- To: "Burdett, David" <david.burdett@commerceone.com>
- Date: Thu, 4 Jan 2001 08:14:11 -0500
On Wed, Jan 03, 2001 at 11:14:48PM -0800, Burdett, David wrote: > Thanks for your comments. We do need to come to closure on the suitability > of URNs which seems to be the main point you quite reasonably are asking. > > The problem I have with using DUNS is that they are not Global, although > they are widely used in America. Therefore IMO, we cannot rely on using only > them. For example, I believe that Japan does not use DUNS much if at all, > but there is another numbering scheme there that is widely used. What do you > suggest as an alternative that allows any popular identification scheme to > be used? Also DUNS has a very strict idea of what a commercial entity is. In many cases what we normally would consider to be a commercial entity is simply ignored by DUNS... You have three routes, IMHO. You can use an existing, low weight namespace such as OIDs, specify how you would use several grandfathered namespaces and use them where appropriate, or roll a novel namespace specification that solves all of your problems... > The second issue is on the use of IANA as a registration authority. We > should not assume that, just because there are not many URNs registered so > far, that it will be so in the future. What we do need to do is determine > whether IANA would be a good organization to be used as a registration > authority for. Have you approached them? For the OID case the IANA assigns a new number whenever requested. They may no determination as to suitability... If you need another namespace its a fairly easy process to define it and specify how the IANA is to assign it. The IANA is awfully resource constrained of late so the process should be as lightweight as possible... > A third question you raise is the doubt that Dun & Bradstreet would register > DUNS as a domain with IANA for use in URNs. I accept that they have not so > far, but that does not mean they would not be prepared to do so in the > future in order to support ebXML. Have you asked them? D&B was very much involved in the original URN work over the past decade and at the time let it be known that they had every intent of doing so. IMHO, the recent list of well recognized namespaces (isbn, OASIS, etc) will probably bring them out of the woodwork so to speak.... > On the question of URLs being insufficient. I agree with you that they not > as stable as ideally would be the case. However this does not mean they > cannot be used. For example, we have customers who identify they trading > partner by their telephone number. As discussed earlier on this list, we > cannot force people to not use numbering schemes that are slightly volatile. > Another use case to consider is where you want to send a message to an email > address which is also used to identify an individual. In this case a URL > could be a good identifier to use for a Party Id. Yep. You have to look at what you are identifiying and why. URNs are required to be bound to their original Resource for an infinite amount of time (that doesn't mean the resource is available anymore, just that the URN hasn't been reassigned to some other Resource). You have to be careful about why you use URNs and where. > Finally your points about the need to be able to tie a PartyId to > information in a certificate are valid and interesting. What do you suggest > for a method of identifying partys that met the following requirements: > 1. can be used to link to digital a certificate > 2. is easily extensible so that new or existing identification schemes can > be added > 3. does not require ebXML to set up its own registration authority > 4. easily supports existing "web" identifiers such as HTTP or SMTP addresses > > Do you think these requirements are a) correct, b) sufficient? IMHO they describe the URI space in general. This is fine but (as we are learning with the XML Namespaces issues) you must be clear about whether you are using URI References and which URI schemes may or may not be appropriate for specific uses... -MM -- ------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC