[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]
Powered by eList eXpress LLC