OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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


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,
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,
>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,
>>the EDI world, Telephone numbers *are* used to uniquely identify a
>>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**
>>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
>>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.
>>-----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
>>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
>>Dick wrote:
>>One requirement:
>>Any two trading partners should be permitted to use non-standard  values
>>context and authority. The specs must provide an extension mechanism to
>>this type of customization.  For example MIME permits header extensions
>>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:
>>rings true with what I had been advocating (use of URI syntax and NO
>>since the URI provides its own context. I could conceive of use of an
>>which allowed typing ala BizTalk (which uses xsd:type to declare the type
>>value, but not necessarily the namespace) as this might be seen as useful
>>parsing the value and would permit non-URI syntax to be used as the
>>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)
>>       case the "From" might be the "mailbox" identifier
>>       into which the MS should place the message received. It isn't
>>       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
>>       and some value (mailbox address).
>>       - logging: an MS might be required to log all messages processed,
>>       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
>>       which might be found in the headers would be useful. Again, it is
>>       not important that the log contain the formal company name
>>       the logical id) in the log file. This could be processed after the
>>       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
>>       less performant) because this can be resolved later when (and IF)
>>       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
>>       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
>>       be required at all. Again, from the MS perspective, it is NOT
>>       that it "know" *who* the entity/party is. The implementation would
>>       have a responsibility to know how to perform the I2L resolution. If
>>       "key" (I) were unique (as is the case of any URI) then there is no
>>       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
>>       of key/value pairs could easily accomodate the mapping.
>>       in the case where a TPA *is* present, then the "To" might be used
>>       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
>>       identifier (possibly, the TPA should have something akin to what
>>       has to associate a number of different identifiers with a
>>       ...) Heck, the PartyId in the Header could be the *same* value as
>>       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
>>       to validate the signature (or passwd) with which the message was
>>       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*
>>so that the MS can resolve it (somehow) to something useful in the MS
>>context. It is not necessary (based upon the use cases above) that the
>>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;-).
>>    _/_/_/_/ _/    _/ _/    _/ 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]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC