[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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:126.96.36.199.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:188.8.131.52.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:184.108.40.2062501225</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