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]


I wholeheartedly concur with Marty's observation and recommendation.
If we allow this in the design, the practice should be strongly
discouraged.

Cheers,

Chris

Martin W Sachs/Watson/IBM wrote:
> 
> I am leery about using phone numbers as party IDs.  While a phone number
> doesn't change too often phone number change events have been very frequent
> across the country as a whole, at least in the United States, as existing
> area code regions are partititioned. It is true that when a company or
> individual has its phone number changed, a lot of people have to be
> notified and a few more changes, in profiles in registries, do not make
> much of a difference in the notification effort.  Still, the consequences
> of a wrong phone number, used as a party ID  in e-business, may have much
> greater impact than when the phone number is used only for human to human
> contact.
> 
> Businesses should not be prevented from using their phone numbers as party
> IDs, but the practice should not be encouraged.
> 
> Regards,
> Marty
> 
> *************************************************************************************
> 
> 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
> *************************************************************************************
> 
> "Brunner, Eric" <EBrunner@Engage.com> on 09/21/2000 01:01:47 PM
> 
> To:   "'Christopher Ferris'" <chris.ferris@east.sun.com>, ebxml transport
>       <ebxml-transport@lists.ebxml.org>
> cc:
> Subject:  RE: [Fwd: RE: on the issue of PartyId]
> 
> 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

-- 
    _/_/_/_/ _/    _/ _/    _/ 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