RE: Message Service Specification Version 0.91

["Burdett, David" <david.burdett@commerceone.com>]

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:wkammerer@foresightcorp.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: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>

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"