[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Message Service Specification Version 0.91
William 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? 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? 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? 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. 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? Thoughts? David -----Original Message----- From: William J. Kammerer [mailto:email@example.com] Sent: Wednesday, January 03, 2001 4:40 PM To: ebXML Transport (E-mail) Cc: Michael Mealling Subject: Re: Message Service Specification Version 0.91 The Message Service Specification for ebXML Transport, Routing & Packaging, Version 0.91, continues to show the <PartyId> element, in section 8.4.1 - From and To elements, at line 493 with an optional "type" attribute. If "type" is specified, then the trading partners have to agree on what they mean by "type" - not unlike the old "ZZ" or "ZZZ" placeholders (by mutual consent) in X12 and EDIFACT. The only alternative is to use a URI (implied by omission of the "type" attribute). 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. 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. 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:220.127.116.11.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:18.104.22.168.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:22.214.171.1242501225</PartyId> 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. 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"
Powered by eList eXpress LLC