[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [Fwd: RE: on the issue of PartyId]
Marty,
E.164 formatted international telecommunication numbers are globally unique.
Quoting from one of our drafts (getting from a telco # to a dns entry)
...
To find the DNS names for a specific E.164 number, the following
procedure is to be followed:
1. See that the E.164 number is written in its full form, including
the countrycode IDDD. Example: +46-8-9761234
...
And from another one of our drafts (what's what)
...
E.164 numbers, short codes, service codes and prefixes are
categorized in dialing plans. A prefix is an indicator consisting
of one or more digits that allows the selection of different types
of number formats, networks and/or services. Prefixes are not part
of the number and are part of a dialing plan. The uses and the
formats of prefixes are a national matter. Short codes, e.g.
emergency, or service codes may be used based on the national
numbering plan. Those codes are not universal and typically valid
only within a numbering domain identified with the same country code
or country code + network identification code.
...
The example you cited (location-dependent "numbering") is actually an
instance
of a location-dependent dialing plan, not an actual end-point identifier. To
put this in packet-esse, some local routing information has beed embedded in
the
end-point address (bleech!).
Cheers,
Eric
-----Original Message-----
From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
Sent: Sunday, September 24, 2000 9:38 AM
To: Brunner, Eric
Cc: Brunner, Eric; 'Christopher Ferris'; ebxml transport
Subject: RE: [Fwd: RE: on the issue of PartyId]
Eric,
Perhaps you are right. In any case, my bottom line was "let's provide the
capability of using a phone number as a partyID but not require anyone to
use it".
By the way, are phone numbers internationally unique? The prefix for
making an international call varies from country to country and of course
is absent when calling within the same country. Could a given country have
a domestic phone number which has the same digits as the string of country
code plus number for a number in a different country? Also, in some
countries the area code field is prefixed by zero when calling from a
different area in the same country but the zero is omitted when calling
from a different country. The whole area code is (usually) omitted when
calling within the same area.
Is there a defined representation of a phone number which is globally
unique without requiring special-case processing which is different
depending on where the processing takes place and which country the number
is in? I guess the area code is not a problem as long as the number is not
actually used to dial over the PSTN (always include the country code and
the zero preceding the are code for those companies which use the zero).
It is less clear what to do about the international dialing prefix unless
numbers are guaranteed internationally unique without it.
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/24/2000 09:02:15 AM
To: Martin W Sachs/Watson/IBM@IBMUS, "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]
Marty,
Putting on my ENUM WG (IETF, Transport Area) hat, and a few other bits of
cosmetic millinary, I see the question slightly differently. I _do_ think
the historical experience of renumbering isn't a reliable guide, I _do_
think that non-portable numbering isn't a reliable guide, and I _do_ think
that PSTN end-point identifiers (phone numbers) are reasonably useful
persistent identifiers for a larger class of services than historic voice
and text for the hearing impared.
The full text of the ENUM WG charter is at
http://www.ietf.org/html.charters/enum-charter.html.
<enum_charter>
Telephone numbers now identify many different types of end terminals,
supporting many different services and protocols.
Telephone numbers are used to identify ordinary phones, fax machines,
pagers, data modems, email clients, text terminals
for the hearing impaired, etc.
A prospective caller may wish to discover which services and protocols are
supported by the terminal named by a given
telephone number. The caller may also require more information than just
the
telephone number to communicate with the
terminal.
As an example, certain telephones can receive short email messages. The
telephone number is not enough information to
be able to send email; the sender must have more information (equivalent to
the information in a mailto: URL).
From the callee's perspective, the owner of the telephone number or device
may wish to control the information which
prospective callers may receive.
The architecture must allow for different service providers competing
openly
to furnish the directory information required
by clients to reach the desired telephone numbers.
</enum_charter>
Eric
-----Original Message-----
From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
Sent: Saturday, September 23, 2000 4:50 PM
To: Brunner, Eric
Cc: 'Christopher Ferris'; ebxml transport
Subject: RE: [Fwd: RE: on the issue of PartyId]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC