Registry/Repository questions and comments

["William J. Kammerer" <wkammerer@foresightcorp.com>]

In ebXML RegRep Security-003.doc, does "DN" refer to a Distinguished
Name?

I see that a certificate is required in order to contribute information
to the Reg/Rep.  But must this certificate be signed by a trusted
third-party, or can a self-signed certificate be used?  If the latter,
what's to keep just anyone from creating entries for General Motors in
the Registry?  With lights-out open-EDI, I could see the ebXML Registry
used to access information on trading partners, and that information has
to be completely trustworthy as having come from whom it purportedly
represents.

Let's talk use cases. In RegistryServicesSpecificationv0-82.pdf, Line
297: Section 5.2.6 "Buyer Discovers The Seller": "The buyer browses the
Registry using a Registry Browser GUI tool. The buyer searches the
Registry for suitable sellers according to the flexible classification
schemes supported by the Registry. For example the buyer may search for
all parties that are in the Automotive Industry, play a seller role,
support the Rosetta Net PIP3A4 process and sell Car Stereos. The buyer
discovers the seller's CPP and decides to engage in a partnership with
the seller."

I notice that the AIAG is represented among the Reg Rep participants.  I
might be all wet. I don't know the auto business. But c'mon:  would
Volkswagen really "discover" car stereos this way?  Or is it just
because VW doesn't have ebXML - to show them they have alternatives -
that they've put Bosch radios and spark plugs, etc. etc. in every VW
since the Third Reich? The manufacturers' supply chain partnerships are
based on long-standing relationships involving trust.  Just look at Ford
and Firestone - it took a trauma like the exploding radials to break
apart a 98-year company partnership, which included Ford-Firestone
dynastic marriages along the way! This "discovery" crap sounds like
e-marketplace hype which only analysts and VC would swallow. If Ford
wants to "discover" a direct supplier, their own buyers and engineers
know where to look - they don't need ebXML.

This reminds me of "registries" like the Phillips EDI Yellow Pages,
which were certainly not used to find alternative suppliers, but rather
to obtain current trading partner information like the EDI contact name
or VAN and protocol information.  Actually, the EDI Yellow Pages was
more useful to EDI vendors for hawking their warez. The Yellow Pages
was always a marginal business, then eventually moved to CD-Rom and then
to the Web by Phillips Publishing, when it was eventually abandoned.
This kind of EDI Yellow Pages or Directory stuff has never worked
because it didn't make any economic sense. Mike Rawlins would not be as
generous as I in appraising the EDI Yellow Pages; see
http://www.metronet.com/~rawlins/bookmag.html, where he says "I can't
imagine looking up EDI contacts of potential trading partners using this
book, as there are much cheaper and more reliable ways to get that
information."

The typical semi-rational person will ask "What's in it for me?" when
asked to laboriously plod through some sort of online registry to enter
his company and trading partner information.  I know:  I just did it for
kicks at the Ariba UDDI site, but I don't think there's a rat's ass
chance anybody's going to be plowing through the UDDI registry looking
for software providers of EDI productivity tools or Web-based EC, based
on my SIC code or location in East Bumf*ck, Ohio.

More plausible scenarios involve trading partners known to each other
who wish to enhance their current relationship.  A first scenario would
be engaging an SME in the most rudimentary electronic commerce.  Take
FORESIGHT Corp., for example.  We do zilch EC - a classic case of "`the
cobbler's children have no shoes." So far it just wouldn't be worth it -
a few thousand customers, a few hundred vendors.  We're certainly not
going to spend the time soliciting trading partners for EC.  But you
could probably talk our Controller into registering with a "global"
ebXML registry saying we're ready and willing to take any kind of
invoice via e-mail.

Even though most of our vendors are relatively small, and would likewise
achieve no economies in searching us out on the ebXML registry, there
are a few big or technologically savvy ones who might want to reach us
electronically with invoices or statements.  As examples:  Qwest -  the
phone company, AEP - the electric company, ADP - the payroll company,
the IRS - the protection racket company, American Express, our ISP, and
maybe some insurance companies and banks.  Each of these outfits have
hundreds of thousands or millions of business customers, and it would
probably be worth their while to engage us, and every other one of their
SME customers, electronically - if only they could  "find" us and "hook"
up to us electronically.

Let's look at Qwest:  we get a big itemized phone bill from them each
month on paper in the mail.  We don't or can't do too much with the bill
now - there's just too much detail and can't be put into a spreadsheet.
Right now I think Accounts Payable just eyeballs the bill to see if I've
made any 1-900 phone sex calls, does a sanity check on the total, and
then pays it.  What if Qwest "discovered" us in the ebXML Registry,
marked as willing to take electronic invoices, even if only in "baby"
steps? Maybe we would specify that we want a "print" image in PDF, Word
or Excel.  Perhaps short of an X12 811 Consolidated Invoice, that's all
Qwest would be able to provide for now.   Qwest would probably find us
by DUNS or Tax ID, information they could easily obtain from D&B or
Lycos' Companies Online at http://www.companiesonline.com if they hadn't
already asked us for these IDs when we started service with them.  Using
the company name to search for us would make the "discovery" difficult
to automate as the name could be spelled any number of ways.

Once they "found" us, they could do a little due diligence - like send a
notice to the normal billing address saying they're going to start
sending ebXML messages by SMTP instead of the normal printed invoice
starting next month to the e-mail address found in the Registry under
our entry.  They'll confirm that the invoice will be in PDF in a payload
attachment, but that we can optionally receive a TCIF XML version of the
invoice in the future if we indicate our preference in the ebXML
registry.  When the invoice comes in via e-mail, Nettie's going to be
surprised when she clicks on the message and sees a bunch of XML from
the ebXML Header Envelope.  Instead,  I hope that a plain text or HTML
message can be sent along with the ebXML Message Envelope which can be
read by a human telling her to click on some attachment in the payload
for the PDF file.

This all sounds great, even if for the first year or so all we do is
read a PDF instead of a printed invoice.  If the network effect is great
enough, and enough SMEs are thus "discovered," Qwest saves enough for a
few management bonuses in printing and postage.   We, the SME,  always
had what we had before, but get it slightly sooner.  Win-Win.  Later on,
we might become more venturesome, and ask Qwest to send us their XML
version by noting we're ready to take XML TCIF invoices in the registry.
Assuming the XML is accompanied by a style sheet for presentation, we
can take our time in getting used to that.  When we're ready to take the
*big* step, maybe we'll have some means of getting the XML invoice into
an Excel spreadsheet or Quick books so we can do cost allocation, which
we had never done before. Even at this point, we haven't had to make any
investment in software or learn radically new procedures.  The ebXML
e-mail invoices come into Outlook Express just like any other e-mail.

One baby step at a time.  As confidence builds, we may even venture out
to the ebXML registry looking for our own customers - generally the
Global 2000 - who are willing to take invoices by e-mail.  If we
"discover"  more than a hundred or so ready and willing, maybe it will
be worthwhile to take the plunge.  Perhaps we'll graduate to producing
XML invoices.  Who knows?

All this presupposes adequate security.  You have to be sure that some
trusted authority has vouched for the certificate being used to
"identify" the SO.  The only thing that kept me from creating a phony
entry for Intel in the UDDI registry was the stupid disclaimer at the
start of the process.  Normally my conscience wouldn't stop me from
wreaking havoc in a case like this, but then I wouldn't be using my own
name to talk about it.  Would I?

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"