Re: Trading Partner Logical Identification based on EDIFACT or X12qualifiers

[dick@8760.com]

Let me attempt to identify what we are agreeing and disagreeing on:

WE AGREE that "context" and "authority" elements are needed in order to identify
and validate the information contained in the PartyId element.

WE HAVE NOT AGREED on the values used in "context" which qualifies the semantics
of "authority".
In other words one cannot determine that authority=1 MEANS DUNS number without
knowing the "context", which in effect identifies the list of valid values that
can be used in the "authority" attribute.

ACTION ITEM 1 - identify a core set of values that can be used in the "context"
attribute.

WE HAVE NOT AGREED on who gets to choose the set of "context" values (regrep,
TRP, CC).

ACTION ITEM 2 - decide which group should define the list of values for
"context".

I propose we address action item 2 first and 1 will soon follow.

One requirement:

Any two trading partners should be permitted to use non-standard  values for
context and authority. The specs must provide an extension mechanism to allow
this type of customization.  For example MIME permits header extensions through
the X-hhhhhhh option, X12 has the "ZZ" qualifier, etc. Consider a possible
example, using Amazon:

<PartyId context="X-Amazon" authority="userid">RJB9876</PartyId>


This, I believe, would address David B's concern over having parties
pre-register with recognized "Name space management organizations".



----- 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: Monday, August 14, 2000 7:34 PM
Subject: RE: Trading Partner Logical Identification based on EDIFACT or X1
2qualifiers


List-Unsubscribe:
 <mailto:ebxml-transport-request@lists.ebxml.org?body=subscribe>
List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
 <mailto:ebxml-transport-request@lists.ebxml.org?body=lp>

Dave,

Now we get into the tertiery layer of comments on comments on comments!

I think we need a repository of comments! ; -)  Anyway - see annotation
below....

DW.
================================================
Message text written by David Burdett
##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.##
and
##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.##
>>>>>>>>>>>>>>
Dave the key is the BUSINESS context here.   Everyone focuses on
technology but the bits and bytes must follow business logic and use.

So -sure - individual industries will go with what makes sense.  The
whole point that William made was CONTEXT rules.  So Compaq has
a DUNS # - and that industry likes DUNS.  Another industry may
prefer US IRS EIN as an ID.  Who cares - so long as they can indicate
that to their trading partners....that is the key.  I do NOT see
repositories
doing this allocation - thats a specialized task - the repository merely
stores values it is given.  We are not mandating UN/EDIFACT or any
other labelling scheme - but merely allowing whatever industry selects.
<<<<<<<<<<<<<<

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

>>>>>>>>>>>>>
Since my company has a digital signature product I have to agree whole
heartedly with you here!!  However - first point of contact is critical.
Nothing to stop someone setting up a bogus company - applying for
and getting a perfectly legal DSig - and then causing mayhem.
Anyway - again - that's a function elsewhere NOT the transport and
repository.  The tracking mechanisms should identify the fraud so
that law enforcement can do their job.  Such tracking then acts as
a good deterent itself.  So long as the transport header can validate
that X sent Y on and at Z, we have done our job.
<<<<<<<<<<<<<<<<<

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

>>>>>>>>>>>>>>>>
Yes - if you look at the GUIDE mechanism - you see that an application
can choose the information it requires.  It may issue a directed query
(using IDREF) to retrieve just the part of the information set that it
requires and get back a fragment of an XML instance at the correct
parent level it queried on.   You can't do that cleanly with a URN.
<<<<<<<<<<<<<<

[clip]
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.##

>>>>>>>>>>>>>>>>

Oops!  Did I mention I'm co-chairing the RegRep WG and I'm just over
here fact gathering to help us in our spec's?

Agreed - this is something that is an activity that TRP identify the need
and then let RegRep figure out the details of how best to implement.
So from the TRP side it just looks like a hook in the sky.

Actually the base need has already been defined in the Requirements
and Tech Arch', and I see it boils down to two high level functions:

1) Registry to provide TPA profile querying and registration, and
     then the preferred transport header interchange schema format.

2) Repository to provide lookup of definitions of any element
     from within a transport header to determine valid semantics.

Thanks, DW.