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

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

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