Re: [Fwd: RE: on the issue of PartyId]

[Chris Ferris <chris.ferris@east.sun.com>]

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