RE: Trading Partner Logical Identification based on EDIFACT or X12qualifiers

[Dick Brooks <dick@8760.com>]

David,

I may be missing your point but it seems to me it is ebXML's duty to deliver
a set of specifications that will ensure a high degree of interoperability
throughout a large, diverse business community.  We must recognize the
different "way business may be conducted" and degrees of "capability" that
may exist within that community:
- system-to-system with extensive resources and capabilities (e.g. Enron)
- interactive with human intervention (e.g. Amazon)
   - thin client
   - fat client
- Multi-party with intermediaries (e.g. portals, VAN's, ASP's, other 3rd
parties)

ebXML should be solution for all the above and we cannot mandate the use of
an ebXML specified repository, particularly in the interactive/thin client
case.

I also believe the more we can explicitly and unambiguously define in the
specs the greater our chances for success meeting the interoperability
challenge. I DO recommend that we define a core set of "standard" values for
the PartyId/context in order to ensure a "lowest common denominator", PLUS
add an extension capability for those who wish to engage in a mutual consent
arrangement. I DON'T believe an API for regrep/TA will circumvent the need
to define a standard set of options for PartyId/context, especially in the
case of an interactive/thin client. I DO believe we need an API for
regrep/TA for those implementations that can benefit from having an ebXML
compliant repository available.

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: David RR Webber [mailto:Gnosis_@compuserve.com]
> Sent: Tuesday, August 15, 2000 3:15 PM
> To: INTERNET:dick@8760.com
> Cc: David Burdett; ebXML Transport (E-mail)
> 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>
>
> Arrrrggghhh!
>
> Dick this is NOT what I had in mind.  Its good that we're having this
> dialogue.
>
> Your TPA determines who/what/where - even if, as Rachel pointed out,
> the TPA you are using is actually a proxy TPA (becuase you are just a
> consumer)
> thru your ISP or merchant or software vendor or similar.
>
> Where does the TPA live?  In the Registry.  Where do the definitions that
> the
> TPA  reference live? In the Repository.
>
> Here's the sequence.
>
> Transport layer receives Header. Inspects - sees reference to Context it
> does not
> already know.  Queries Repository for definition of Context (the bit your
> are probably
> missing here is that the Schema or DTD associated with the
> transport header
> contains
> the XML IDREF lookup into the repository for this) - so the 'flavour' of
> ebXML header
>  you are using already points to these cross-references.
>
> Now armed with this info' the Repository tells you this should be a
> X12/DUNS combo.
> You can then use this to reference TPA from the Registry and validate the
> header.
>
> So - in answer to your question - NO - we should not be defining
> what codes
> lists we
> use - only a SAMPLE of using code lists, and how if someone wants
> to define
> or
> use others - they can easily add them.  Remember - we do the technical
> spec's,
> then businesses determine the actual information content based on business
> need.
>
> So the action item is -
>
> 1)  Pester Tech Arch and RegRep to define interface spec's -
>         these are somewhat there in doc's - but need better use cases et
> al.
> 2)  Pester RegRep to give spec's on API for 1) -
>         we're working on those hot and heavy for the POC - more soon,
>        but not too soon  - I've lots of project work over next couple of
> weeks....
>
> Thanks, DW.
> ========================================================================
>
> Message text written by INTERNET:dick@8760.com
> >
> 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".
>
> <