[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] CPPA version 1.10
In reality, I think that most people would be very reluctant to give out either or these 2 numbers however, the concept is good. Duane Martin W Sachs wrote: > > I agree regarding social security number. However Chris also mentioned > taxpayer ID number. I believe that UDDI also provides for identification > by taxpayer ID. For a business, that isn't a problem regarding SSN. Of > course it raises an interesting question for individuals. Still, it would > be up to an individual operating as a business to get a taxpayer ID that is > not his/her social security number. > > Regards, > Marty > > ************************************************************************************* > > Martin W. Sachs > IBM T. J. Watson Research Center > P. O. B. 704 > Yorktown Hts, NY 10598 > 914-784-7287; IBM tie line 863-7287 > Notes address: Martin W Sachs/Watson/IBM > Internet address: mwsachs @ us.ibm.com > ************************************************************************************* > > |---------+----------------------------> > | | David Fischer | > | | <david@drummondgr| > | | oup.com> | > | | | > | | 03/15/2002 03:51 | > | | PM | > | | | > |---------+----------------------------> > >-------------------------------------------------------------------------------------------------------------------| > | | > | To: Christopher Ferris <chris.ferris@sun.com>, CPPA <ebxml-cppa@lists.oasis-open.org> | > | cc: | > | Subject: RE: [ebxml-cppa] CPPA version 1.10 | > | | > | | > >-------------------------------------------------------------------------------------------------------------------| > > Chris, you are right on the mark. > > However, SSN is a bad example. The legislation which instituted these > numbers > specifically stated that they NOT be used as a universal identifying number > -- > even though they are used that way quite often, even by state governments. > There are some privacy issues there which it would be best to avoid. > > I wonder if it would be better to focus (not exclusively) on something more > global -- like UCC/GLN -- rather than DUNS. I absolutely agree though that > there doesn't/shouldn't need to be any *single* central authority for the > identifiers. I assume that SMEs will end up using eMail addresses as a > start. > > Regards, > > David. > > -----Original Message----- > From: Christopher Ferris [mailto:chris.ferris@sun.com] > Sent: Friday, March 15, 2002 2:24 PM > To: CPPA > Subject: Re: [ebxml-cppa] CPPA version 1.10 > > Duane, > > Please see below. > > Chris > > Duane Nickull wrote: > > > Chris: > > > > If I thought that would solve the problem, I would have done this. The > > problem is that a DUNS number is not as easy to get once you are outside > > the confines of the US. > > That isn't the point. The point shouldn't be to identify a registry > like DUNS that everyone can, should or must use, it should rather be to > provide a means that an identifier can be used and mutually understood > without requiring a centralized process or registry. > > A URI provides this capability, that is its purpose. If I had > my druthers, I'd prefer to see that there were no 'type' attribute > but that the value be required to be a URI. > > More below. > > > > > I agree that we cannot close the list. Here is a copy of the email I > > sent to Dale (Sorry - meant to copy the list): > > > > ******* MESSAGE ************ > > Dale: > > > > Here are the requirements for this artifact: > > > > 1. It can globally, uniquely identify a company > > why limit to a company? > > > 2. It is available to any company (worldwide) without unreasonable > > overhead. > > agreed. > > > 3. Sub-groups within a company MAY need to uniquely identify themselves > > as a subgroup but within the domain of the company. > > agreed. > > > > > On the wish list: > > > > 4. It can be used to get more definitive information about a company. > > > > I think that URI meets all of the requirements and I would be happy for > > now. Dun and Bradstreets numbers are not easy to acquire globally, > > therefore are not as desirable for non-USA companies. DUNS is nice > > though becuase it says that the company has undergone some sort of > > screening process but that would only be useful if there was a way to > > verify that the DUNS number was legitimately issued, which there is not > > (not without manual intervention.). > > > > > Other items like tax id numbers may be used (need to clarify if they are > > globally unique if used with a country qualifier) or a unique number > > registered with a global authority like IANA. > > Or just an adopted URN namespace e.g. urn:www.ssa.gov:ein:123456789 or > urn:www.ssa.gov:ssn:123456789. The namespace becomes the qualifier for > the raw ssn or ein number which is managed by the authority that owns > the URN namespace (in this case, the entity www.ssa.gov which is the > US Social Security Administration). (note that I'm unclear as to > whether the SSA assigns EINs or if this is maybe a function of the > IRS) > > The whole point here is that there not need to be a *single* > central authority for the identifiers, but that those authorities > that are already in place merely ask for a URN namespace that > can be applied to their existing identifiers so as to fully > qualify them so that it can be globally recognized and we can > end this never-ending debate (which has resurfaced more times > in the context of ebXML than I care to recall!) > > > > > Duane > > > > ***************************** > > > > I have no other ideas off the top of my head. I am glad everyone at > > least agrees this is a problem. > > > > Duane > > > > Christopher Ferris wrote: > > > >>Duane, > >> > >>Sure, we could define an enumeration that included > >>DUNS, but there are many others out there. If the > >>enumeration is used, then it is effectively a closed list and only the > >>owners of the schema can extend to add other namespaces. > >>This approach seems to me to be quite unnecessarily constraining. > >> > >>Why don't you lobby D&B to get (or publicly declare) a > >>namespace identifier. This has only been an issue for > >>I don't know how long. Seems to me that the UN could > >>excersize some of its clout to encourage D&B to help > >>with this problem. > >> > >>Just establishing a closed enumeration is NOT IMO > >>a viable solution to this issue and I won't support > >>it if we choose this route. > >> > >>Cheers, > >> > >>Chris > >> > >>Duane Nickull wrote: > >> > >> > >>>>Tony Weida wrote: > >>>> > >>>>CPPA version 1.10 is attached. > >>>> > >>>> > >>>Tony and all: > >>> > >>>Until the issue of PartyID attribute "type" is resolved, I wil not > >>>support this document. I wish to suggest the changes. > >>> > >>>Currently you have: > >>> > >>><element name="PartyId"> > >>> <complexType> > >>> <simpleContent> > >>> <extension base="tns:non-empty-string"> > >>> <attribute name="type" type="tns:non-empty-string"/> > >>> </extension> > >>> </simpleContent> > >>> </complexType> > >>></element> > >>> > >>>There has to be somthing sematically meaningful for this to be a party > >>>identifier. For now, I suggest the following: > >>> > >>>Change the attribute content model to an enumerated list of > >>> > >>>( DUNS | URL | ... ) > >>> > >>>and allow companies to chose one of several types of PartyID's that are > >>>guaranteed to be unique. If DUNS is guaranteed unique, then it can be > >>>used but you must specify the semantics of DUNS somewhere. I suggest > >>>you put this in the specification that governs this schema. Clearly > >>>state that " a value of "DUNS" indicates the Dun and Bradstreets > >>>identification number of the company as given by ...". Make the same > >>>type of statement for any other unique identifiers types you allow int > >>>he enumerated list. For instance, "URL is instance value of a properly > >>>formed URL owned by the Trading Partner.." > >>> > >>>Otherwise, this is completely useless and will not meet the > >>>requirements of CPPA. > >>> > >>>Please give this some serious thought. We can always expand the > >>>enumerated list later based on requirements of companies. > >>> > >>>Duane Nickull > >>> > >>> > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> -- CTO, XML Global Technologies **************************** Transformation - http://www.xmlglobal.com/prod/foundation/ ebXML Central - http://www.xmlglobal.com/prod/central/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC