[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Trading Partner Logical Identification based on EDIFACT or X12qualifiers
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 <email@example.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:firstname.lastname@example.org?body=subscribe> List-Archive: <http://lists.ebxml.org/archives/ebxml-transport> List-Help: <http://lists.ebxml.org/doc/email-manage.html>, <mailto:email@example.com?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.
Powered by eList eXpress LLC