RE: Trading Partner Logical Identification based on EDIFACT or X12qualifiers

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

Gordon said ...

"why are we creating a barrier then for SME's?"

It's because I *think* the proposal would *require* every organization to
register themselves within an ISO/X12/EDIFACT registry before they could use
TRP messaging.

David

-----Original Message-----
From: Jenkins Gordon [mailto:gjenkins@singnet.com.sg]
Sent: Monday, August 14, 2000 3:49 PM
To: David RR Webber; David Burdett
Cc: ebXML Transport (E-mail)
Subject: Re: Trading Partner Logical Identification based on EDIFACT or
X1 2qualifiers


David
Sorry I am missing what is probably obvious point
- why are we creating a barrier then for SME's?
Regards
Gord
Gordon Jenkins
Standard Chartered Bank
Corporate & Institutional Banking
51 Bras Basah
SINGAPORE 189554

Email : gjenkins@singnet.com.sg

Tel :65-331 5095
----- Original Message -----
From: David RR Webber <Gnosis_@compuserve.com>
To: David Burdett <david.burdett@commerceone.com>
Cc: ebXML Transport (E-mail) <ebXML-Transport@lists.ebxml.org>
Sent: Tuesday, August 15, 2000 6:24 AM
Subject: RE: Trading Partner Logical Identification based on EDIFACT or X1
2qualifiers


Message text written by David Burdett
>The thornier question is WHO decides what goes in the repository. Because
if
we require that companies/organizations/individuals are registered before
they can use ebXML then:
a) we are creating a barrier for SMEs - which is against our objectives
b) whoever controls access has a lot of power ... which they probably
shouldn't have.

To my mind, the relative open access provided by the existing Domain Name
System (via URN/URIs), is something we should leverage whilst still
allowing
existing naming/numbering schemes from ISO/X12/EDIFACT to co-exist.

David
<<<<<<<<<<<<<<

These are only issues in our minds (mostly!).

The tpaML thing is where the rubber hits the road.  If I can have a tpaML
profile where most of it is 'none / default / any / unknown' then its easy
for a SME to join up.  Actually their ISP should provide defaults
automatically
of any domain stuff into a tpaML profile - so they won;t even see that.

I do NOT think there will be a power issue - because frankly ANY repository
can play - so that means rapidly you have competition on providing access.

You have to have some accountablity and traceablity to avoid fraud (there
will
be fraud - nothing is 100% - but you should strive for 90%+)

Domain names just do not give you any sort of granularity into information.
The use of namespace as a qualifier (as in GUIDE) is OK - but then you
need specific labels (IDREF's) within that to locate what you need.

Whether the namespace points at some complex registry/repository, or
if the Reg/Rep is in fact a simple XML file stored in a sub-directory and
the Web server can do IDREF style query against the content (i.e. extremely
simple) that is really an issue of implementation.

Then there's the impending Schema support issue.  GUIDE is an approach
to letting you do both - and uses reference mechanisms that work well
in both worlds.  Simple URN is going to have a tough time with Schema
extensions, but that's a technical aside, returning to the business
focus....

I'd like to see the Transport layer 'repository enabled' so that these
references can be resolved simply and easily, while at the same time
providing robust and honest information retrieval.   This is not difficult
to
do with simple http based query/response, and definately adds
significant value to an interchange header in terms of interoperable and
secure exchanges.

We've never said there is a restriction on content - just that content
needs to be authenticated - the difference between a Yahoo search
engine and an Ask Jeeves - its all in that business classification layer
in GUIDE!

That's why I noted that some of this is to be determined as we work toward
Tokyo.

Thanks, DW.