Re: Message Service Specification Version 0.91

[Christopher Ferris <chris.ferris@east.sun.com>]

William/All,

Please see my comments below.

Cheers,

Chris

"William J. Kammerer" wrote:
<snip/>
> 
> > 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....

Yes, this is both accurate and interesting, but at the same time
might be confusing and lead to interoperability issues because 
a single namespace (oid) can resolve an entity (party) multiple
ways using different values for the OID, each based on a different
NSS heirarchy. This *could* be expressed in the CPP/CPA by identifying
the preferred "root" (e.g. urn:oid:1.3.60 vs urn:oid:1.3.6.1.4.1.519.1
vs urn:oid:1.3.6.1.4.1) for the partyId URN should the OID namespace
be used.

> 
> > 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....

This is, I believe, what David and I have been saying all along.
I've even seen at least one namespace request for an individual
(Norm Walsh, a colleague of mine).

I suppose that D&B *could* leave things as they are and have
the "normative" URN for DUNS numbers be: 
	urn:oid:1.3.6.1.4.1.519.1.<DUNSNUMBER>

However, it would seem to me that it would be in their interest
to register a formal (or informal) namespace i.e. urn:duns:<DUNSNUMBER>
to make it unambiguous. They could then establish a N2I or N2L
resolution service (based on DNS? THTTP? other?)

Has anyone asked D&B if this is in their plans? Have they even
considered it? (reading below... I see that they have, but haven't
gotten around to it yet...;-)

> 
> -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
> 
>   ----------------------------------------------------------------------------------------------------
> 
> Subject: Re: Message Service Specification Version 0.91
> Date: Thu, 4 Jan 2001 08:14:11 -0500
> From: Michael Mealling <michael@bailey.dscga.com>
> Reply-To: michaelm@netsol.com
> To: "Burdett, David" <david.burdett@commerceone.com>
> CC: "'William J. Kammerer'" <wkammerer@foresightcorp.com>,
>      "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
> References: <63751F9A4BBBD411A6E000508BA5831F9B10CB@c1plenaexm03.commerceone.com>
> 
> 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....

One can only hope!

> 
> > 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.

The example that William cited previously (Delta) suggests that a 
domainname may NOT be the most appropriate choice for PartyId
as it can change overnight!

> 
> > 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..

Agreed, but as there is no uber-namespace ebXML will have to accomodate
a varying set of schemes. I agree that we should make it clear as to
which schemes are appropriate and those which we believe to be unstable
or inappropriate for this purpose.

> 
> -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
begin:vcard 
n:Ferris;Christopher
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
adr;quoted-printable:;;One Network Drive=0D=0AMS UBUR02-201;Burlington;Ma;01803;USA
x-mozilla-cpt:;-20624
fn:Christopher Ferris
end:vcard