[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [Fwd: RE: on the issue of PartyId]
Chris, First, I'm ok with your DTD snip. (and yes Henry "type" could basically mean "context", but I'm ok with either one) Second, I agree that the value of "type", or the absence of it, needs to be agreed upon between Partys. I would prefer to keep the "where it must/may reside" (tpa, header, or on the moon) into a seperate issue....... Scott Hinkelman Senior Software Engineer, IBM Austin Emerging Technologies, SWG 512-823-8097 (TL 793-8097) (Cell: 512-940-0519) srh@us.ibm.com, Fax: 512-838-1074 Chris Ferris <chris.ferris@east.sun.com>@bast.Corp.Sun.COM on 09/21/2000 03:34:40 PM Sent by: cferris@bast.Corp.Sun.COM To: ebxml transport <ebxml-transport@lists.ebxml.org> cc: Subject: Re: [Fwd: RE: on the issue of PartyId] If we could agree that it must be agreed and specified in the TPA then I guess I'm cool. How 'bout: <!ELEMENT PartyId (#PCDATA)> <!ATTLIST PartyId type CDATA #FIXED 'uriReference'> Cheers, Chris Scott Hinkelman/Austin/IBM wrote: > I'm ok with David's "other hand" proposal. As long as we don't dictate what > it *must* be. > > Scott Hinkelman > Senior Software Engineer, IBM Austin > Emerging Technologies, SWG > 512-823-8097 (TL 793-8097) (Cell: 512-940-0519) > srh@us.ibm.com, Fax: 512-838-1074 > > "Burdett, David" <david.burdett@commerceone.com> on 09/21/2000 02:11:12 PM > > To: "'Chris Ferris'" <chris.ferris@east.sun.com>, ebxml transport > <ebxml-transport@lists.ebxml.org> > cc: > Subject: RE: [Fwd: RE: on the issue of PartyId] > > Again > > I agree with Chris, using a URI, removes the problem from TRP of defining > what can validly be present in a context, and allows us to use IANA > instead. > > So I still think we should go with URI as the prime mechanism. > > On the other hand if we really wanted to be flexible though we could have > an > additional alternative of ... > > <PartyId type='userdefined'>123dwqf09u23rnsadp9</PartyId> > > where in the latter case, the recipient is expected to recognize the > PartyId > through a previously mutually agreed mechanism. In addition if type is not > present, then it defaults to 'URI'. This means you either have: > 1. a URI, or > 2. a coding scheme mutually agreed between the parties > > Thoughts? > > David > > -----Original Message----- > From: Chris Ferris [mailto:chris.ferris@east.sun.com] > Sent: Thursday, September 21, 2000 11:49 AM > To: ebxml transport > Subject: Re: [Fwd: RE: on the issue of PartyId] > > A URI provides its own context. This is what I am recommending, not that > any particular context shall be used or excluded (although I pointed out > that telephone # doesn't qualify as an URN which would seem to me > to be the form of URI which would be recommended). > > By that I mean that: > > <PartyId context="duns">1234567890123</PartyId> > > is the same as: > > <PartyId>urn:duns:1234567890123</PartyId> > > and that I would recommend that the latter form be used. > That was the jist of my proposal. > > Cheers, > > Chris > > Scott Hinkelman/Austin/IBM wrote: > > > I agree with Henry. I don't think we should dictate what it is, only > > dictate a way > > to dictate what it is. > > > > Scott Hinkelman > > Senior Software Engineer, IBM Austin > > Emerging Technologies, SWG > > 512-823-8097 (TL 793-8097) (Cell: 512-940-0519) > > srh@us.ibm.com, Fax: 512-838-1074 > > > > Henry Lowe <hlowe@omg.org> on 09/21/2000 01:37:49 PM > > > > To: "Brunner, Eric" <EBrunner@Engage.com> > > cc: "'Christopher Ferris'" <chris.ferris@east.sun.com>, ebxml transport > > <ebxml-transport@lists.ebxml.org> > > Subject: RE: [Fwd: RE: on the issue of PartyId] > > > > While being able to say that PartyID is a URI might nice, > > why is this necessary? Especially if we are trying to > > ensure that we can use all the different sorts of identifiers > > which have been mentioned in Chris' list (below, several > > messages down) plus telephone numbers? > > > > While it's not defined yet in the MS spec., the "context" > > will happily allow us to use any of these schemes as long as > > we define "context" appropriately. > > > > Best regards, > > Henry > > -------------------------------------------- > > At 01:01 PM 09/21/2000 -0400, Brunner, Eric wrote: > > >I concure, and (wearing another hat) am part of the group(s) working on > > >making the e.164 numbering plan map to the dns, hence making "telephone > > >numbers" map to URIs. > > > > > >-----Original Message----- > > >From: Christopher Ferris [mailto:chris.ferris@east.sun.com] > > >Sent: Thursday, September 21, 2000 10:36 AM > > >To: ebxml transport > > >Subject: [Fwd: RE: on the issue of PartyId] > > > > > > > > >nor this one... > > > > > >-------- Original Message -------- > > >Subject: RE: on the issue of PartyId > > >Date: Wed, 20 Sep 2000 22:41:53 -0700 > > >From: "Burdett, David" <david.burdett@commerceone.com> > > >To: Christopher Ferris <chris.ferris@east.sun.com> > > > > > >The bottom line (almost) of Chris' email said ... > > > > > >>>>Thus, I would propose that we adopt use of a URI as the value of the > > >PartyId element.<<< > > > > > >I agree for the reasons Chris gave. The only caveat I would have is > that, > > in > > >the EDI world, Telephone numbers *are* used to uniquely identify a > > business. > > >I therefore think we also need to support this format. > > > > > >Chris is right that telephone numbers can be re-allocated to new > > >individuals/businesses and therefore do not strictly meet the > requirement > > >for a URN on their own. However a telephone number **at a point in > time** > > is > > >unique. Open to alternative suggestions but what might work is to define > > >PartyId with a default type of URI, but allow an alternative of a > > telephone > > >number with a recommendation that the value be considered in conjunction > > >with the date/time that the message was created in order to assure > > >consistent results. In practice though, the probability of a clash is > low. > > > > > >David > > > > > > > > > > > >-----Original Message----- > > >From: Christopher Ferris [mailto:chris.ferris@east.sun.com] > > >Sent: Thursday, September 14, 2000 7:57 PM > > >To: ebxml transport > > >Subject: on the issue of PartyId > > > > > > > > >I scrounged the archives and came up with the following postings on the > > >topic: > > > > > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00073.html > > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00079.html > > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00084.html > > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00093.html > > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00095.html > > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00082.html > > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00098.html > > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00107.html > > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00097.html > > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00111.html > > > > > >I feel that these postings capture fairly well the discussion on > > >PartyId. I have omitted the zillion related postings on whether > > >to regrep or not to regrep on a message send/receipt as irrelevant > > >to the discussion. > > > > > >Dick's posting made a noble attempt to articulate the various > > >points: > > http://lists.ebxml.org/archives/ebxml-transport/200008/msg00098.html > > > > > >Dick wrote: > > > > ------------------------------------------------------------------------- > > >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". > > > > ------------------------------------------------------------------------- > > > > > >David Burdett's proposal: > > >http://lists.ebxml.org/archives/ebxml-transport/200008/msg00082.html > > >rings true with what I had been advocating (use of URI syntax and NO > > context > > >attribute > > >since the URI provides its own context. I could conceive of use of an > > >attribute > > >which allowed typing ala BizTalk (which uses xsd:type to declare the > type > > of > > >the > > >value, but not necessarily the namespace) as this might be seen as > useful > > in > > >parsing the value and would permit non-URI syntax to be used as the > > PartyId > > >value. > > > > > >I think that it is important that we understand (and agree upon) how > this > > >header element will be used within the MessagingService (let us leave > the > > >Application(Support) layer aside for the moment). > > > > > > - routing: an MS might simply be serving as a "mailbox" server > (as > > >many of the > > > existing implementations handle the initial receipt of a message) > > in > > >which > > > case the "From" might be the "mailbox" identifier > > >(mailto:companyX.com) > > > into which the MS should place the message received. It isn't > > >important > > > that the MS "know" *who* companyX.com *is* (e.g. no reg/rep > lookup > > >need be > > > involved). The MS might resolve the "From" id to an address > > >(mailbox, queue > > > whatever) but all that is needed here is a mapping between the > key > > >(PartyId) > > > and some value (mailbox address). > > > > > > - logging: an MS might be required to log all messages processed, > > in > > >which > > > case having the "To" and "From" logged (without having to look > > >anything else > > > up in say a reg/rep or in a TPA store) along with other > interesting > > >bits > > > which might be found in the headers would be useful. Again, it is > > >probably > > > not important that the log contain the formal company name > > (resolved > > >from > > > the logical id) in the log file. This could be processed after > the > > >fact > > > if it was important that this information be known to someone > > >"reading" the > > > log much the same as most web sites merely log the IP address and > > >not the > > > DNS resolved hostname.domainname (which is expensive and makes > the > > >site > > > less performant) because this can be resolved later when (and IF) > > >the > > > log entry needs to be analyzed. > > > > > > - delivery: if we accept David's scenario (and no, I am not;-) of > a > > > TPA-less exchange, then the "To" might be used to map to some > > >physical > > > address using some manner of I2L (URI to URL) resolution (THTTP? > > >DNS?). In fact, > > > if the "logical" address were a URL (which is a URI) then no > lookup > > >would > > > be required at all. Again, from the MS perspective, it is NOT > > >important > > > that it "know" *who* the entity/party is. The implementation > would > > >merely > > > have a responsibility to know how to perform the I2L resolution. > If > > >the > > > "key" (I) were unique (as is the case of any URI) then there is > no > > >need > > > to agree to which code set is used, just that it be unique so as > to > > > enable the resolution service to map the URI to a URL. A simple > > >hashtable > > > of key/value pairs could easily accomodate the mapping. > > > > > > in the case where a TPA *is* present, then the "To" might be used > > to > > > > > > resolve the communication protocol specifics within the TPA > itself > > >(map the > > > PartyId of the Header to the PartyId of the TPA or to some other > > >Party > > > identifier (possibly, the TPA should have something akin to what > > >UDDI > > > has to associate a number of different identifiers with a > > >BusinessEntity) > > > ...) Heck, the PartyId in the Header could be the *same* value as > > >the > > > PartyId in the TPA;-) e.g. tpa:partyid:12345. > > > > > > - security: again, in the absense of a TPA, one might conceive of > > > use of the "From" PartyId used by the MS as a key to a > credentials > > >registry which > > > could contain the certificate (or passwd) which the receiving > party > > >uses > > > to validate the signature (or passwd) with which the message was > > >signed. > > > Of course, this information would be in the TPA (one would > expect) > > >in which > > > case the "From" might be used within the context of the TPA to > find > > > the certificate/credentials. > > > > > >There may be other uses, but I for one cannot think of them (it's late; > -) > > > > > >The bottom line is that the identifier must be unique within *some* > > >namespace > > >so that the MS can resolve it (somehow) to something useful in the MS > > >processing > > >context. It is not necessary (based upon the use cases above) that the > > *who* > > >be resolved from the registry which allocated the id (ISO whatever) > > > > > >Thus, I would propose that we adopt use of a URI as the value of the > > >PartyId element. > > > > > ><element ref="PartyId" type="uriReference"/> > > > > > >with examples such as those (except the urn:tel: example which is to my > > >understanding an invalid URN because it is not persistent) identified > > >in David's email. > > > > > >I do NOT believe that we need to specify a set of > > >code sets other than possibly as examples (NON-NORMATIVE) as to how > > >PartyId may be (should be?) used. That (I believe) should be left > > >to the parties to agree to (can you say TPA? I knew you could;-). > > > > > >Comments? > > > > > >Chris > > > > > > > > > > > >-- > > > _/_/_/_/ _/ _/ _/ _/ Christopher Ferris - Enterprise Architect > > > _/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063 > > > _/_/_/_/ _/ _/ _/ _/ _/ Email: chris.ferris@East.Sun.COM > > > _/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop: UBUR03-313 > > >_/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA 01803-0903
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC