[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [Fwd: RE: on the issue of PartyId]
Scott, Thanks -- you phrased it more concisely that I did. My apologies if my comment about "context" is wrong as it was fixed in 2.1 -- the last version of MS I looked at for "context" was 2.0. Best regards, Henry ---------------------------------------- At 01:42 PM 09/21/2000 -0500, 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