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

[David RR Webber <Gnosis_@compuserve.com>]

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.