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: [Fwd: Re: on the issue of PartyId]

Don't think this got posted to the list.

-------- Original Message --------
Subject: Re: on the issue of PartyId
Date: Fri, 15 Sep 2000 09:34:10 -0400
From: "Martin W Sachs/Watson/IBM" <mwsachs@us.ibm.com>
To: Christopher Ferris <chris.ferris@east.sun.com>

I agree with the comments on the TPA, on permitting parties to agree on
non-standard code sets,  and on the last paragraph regarding the MS
specifying code sets only as examples.

I note that logging does not appear to be within the TRP scope but I think
that we all are beginning to recognize that a real implementation will
include additional critical services in the middleware (that which some of
us have been calling the application services layer).  See the list of BPF
services on one of the charts in my San Jose presentation.



Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com

Christopher Ferris <chris.ferris@east.sun.com> on 09/14/2000 10:56:50 PM

To:   ebxml transport <ebxml-transport@lists.ebxml.org>
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
context attribute
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
of the
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 PartyId

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
     case the "From" might be the "mailbox" identifier (mailto:companyX.com
     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,
     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, in
     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 (resolved
     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
     DNS resolved hostname.domainname (which is expensive and makes the
     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
     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 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
     ...) 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
     to validate the signature (or passwd) with which the message was
     Of course, this information would be in the TPA (one would expect) in
     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