RE: Trading Partner Logical Identification based on EDIFACT or X1 2qualifiers

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

See comments marked wtih ##

David

-----Original Message-----
From: David RR Webber [mailto:Gnosis_@compuserve.com]
Sent: Monday, August 14, 2000 3:24 PM
To: David Burdett
Cc: ebXML Transport (E-mail)
Subject: RE: Trading Partner Logical Identification based on EDIFACT or
X1 2 qualifiers


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.
##I agree, but how would this work where a company is required to have an
ISO/EDIFACT/X12 number, or are you assuming that their ISP will provide then
with one. I don't know enough on how easy it is for companies **anywhere**
in the world to get an id they can use.##

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.

##If repositories can allocate new ids for organizations, does this mean
that they would each have their own "context" that should be used. If they
do then they who decides what new values of context are allowed.##

You have to have some accountablity and traceablity to avoid fraud (there
will
be fraud - nothing is 100% - but you should strive for 90%+)
##I agree, but I think that digital signatures is what you should use to
provide authenticity. The fact that an organization exists in a repository
does not stop another organization from spoofing them.##

Domain names just do not give you any sort of granularity into information.
##I don't see why? Can you explain the problem?##

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.
##I agree that descriptions on how to use registry repository needs to
specified, but it is unclear to me that this should be a TRP
responsibility.##


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.