RE: Party Proposal, and am I missing anything here???

[Doug Bunting <Doug@ariba.com>]

William,

As Chris has said, it's time to leave the topic of support for
intermediaries behind us.  We've made that decision, let's move on.  Or, if
you "can't see much objection", why are you objecting?

The ebXML Registry may eventually provide the value you describe.  Even if
it does, performance may require avoidance of lookups in the central
repository for every document flowing through an intermediary.

Separately from any performance issues: Not only do organizations have
preferences about how they are identified, but they also have preferences
about how they identify others.  In TRP we're addressing (no pun intended)
routing issues.  In that part of the e-Commerce infrastructure, it's very
important that clients provide enough information that servers can easily
forward, authenticate and process their requests.  Hence a need for
identifiers in the intermediary's preferred identification scheme.  Since
there may be multiple intermediaries that are not known to the client when
composing the message, there's no place to inquire which identification
scheme might work best.  We need to identify all parties in multiple
identification schemes.

thanx,
	doug
------
Doug Bunting
cXML Standards Manager
Ariba, Inc.

-----Original Message-----
From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
Sent: January 11, 2001 11:32
To: ebXML Transport (E-mail)
Subject: Re: Party Proposal, and am I missing anything here???

Doug Bunting shared with us his proposed changes to the Message Service
Specification 0.91, adding "It's insufficient in a multi-hop situation
to identify any party using a single scheme (DUNS, SCAC, EAN, whatever).
Without explicit prior agreement on identification schemes for all
parties, it's probably insufficient for ebXML to allow only one
identifier per party even in single-hop situations.  This was issue 10
in our list."

I can't see much objection to identifying either the <From> or <To>
party with one or more <PartyId> elements;  after all, just about every
organization on the planet has a myriad of ways to identify itself using
an ID assignment from any number of internationally recognized
authorities.

But I think it's a little redundant.  Some folks have a preference for
how they are identified - some might choose a DUNS, others an EAN, still
others a HIN, etc., as we've discussed at length before.  Any one should
sufficient for tracking down the destination party.  All of the relevant
IDs for a party should be in the global Registry/Repository within that
party's profile (akin to the UDDI identifierBag).

Surely, a powerful, omnipotent and all-encompassing registry and
repository ("Oz"), which can track down all the plumbers in Cleveland,
Ohio (to take one of the examples in a RegRep e-mail) or tell me who
will sell me car stereos and does Rosetta Net PIP3A4 (a use case in
ebXML Registry Services Version 0.82), could do something as simple as
giving me the public key, the HTTP URL or SMTP e-mail address for the
MSH, and other miscellany of my partner -  assuming I can give it a list
of IDs on which it can search.

And once I have a way to point my ebXML message to that partner,
encrypted with his public key, whatever do I ever need a VAN (or for
that matter, multi-hop) for?

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"