Subject: RE: new ECML v 2 requirements from Nokia

From: "Burdett, David" <[email-masked]>
Date: Tue, 11 Jun 2002 08:01:45 -0700

Chris, Donald, Eric and others

It's a sad but real fact that Standards groups always lag behind the real
world. ISO with their country codes (and currency codes) is no exception.
However the alternative of not following any standard is worse since you
don't get the interoperability we all seek. 

We've faced this exact problem several times before and came up with the
following solution which, although not ideal actually works and is being
used in eCommerce today which. It involves the use of two codes:

1. CountryCode which MUST contain either an ISO3166-1997 compliant country
code or the text "Other"
2. CountryCodeOther, which contains some other, mutually agreed code to
identify a country if "CountryCode" on those few occasions when an ISO3166
code will not suffice. It is only used if CountryCode contains the text
"Other".

This idea is taken from the XML Common Business Language - xCBL
(http://www.xcbl.org) which is a set of XML Business Document definitions
that Commerce One developed and is now being taken as the basis for the UBL
standards initiative (http://www.oasis-open.org/committees/ubl/).

We often come under pressure to add new country codes and, even more, new
currency codes, to xCBL but have always resisted since it is impossible to
do this in a fair way. We simply say, when ISO comes up with a new list we
will use it, but not until.

I hope these ideas help.

David

-----Original Message-----
From: Chris Smith [mailto:[email-masked]]
Sent: Monday, June 10, 2002 9:47 PM
To: Donald Eastlake 3rd
Cc: Eric Brunner; [email-masked]; [email-masked];
[email-masked]
Subject: Re: new ECML v 2 requirements from Nokia

Previously, Donald Eastlake 3rd and Eric Brunner wrote:

> > The big issue is jurisdiction, from which the regulatory circumstances
and
> > taxation consequences of a transaction arise.

> > > I'm not quite so clear on country codes but if you include the codes
> > > reserved in ISO 3166 but not actually issued, I think you cover the
entities
> > > in the Universal Postal Union.  Can you give an example of a
jurisdiction
> > > not covered by that which would be of any significance in this
protocol?

There needs to be a decision regarding a geographical basis vs a
political basis. ISO 3166 refers to "areas of geopolitical
interest", and won't completely resolve the issue for you.

Many embassies are in Washington DC, U.S.A, but the embassies
proper are considered sovereign. Jurisdiction and location
can be independent at times.

> The Navajo Nation, etc., are subordinate entities that are
> "soveriegn" only to the extent that the US allows.

Subject to occasional court decisions, both ways...

> Since you talk about tax consequences, it can vary in the US
> not just on state/indian-nation but also city, county,
> special districts, and who knows what else...

Don't forget parish. Yes, accomodating this could be difficult.
If it was easy we would be done by now...

> So you don't like iso3166. What exactly is your alternative? You make a
> reasonable argument that there is some benefit in being able to extend
> iso3166 codes, the same way the IETF standard lets you extend ISO
> language codes,

Even ISO 3166 documents some of the 'extensions' - witness the
addition of "ca-nu". But it also clear that in some cases, the
chain of jurisdiction does not flow all the way back to "ca".

So, the choice would appear to be between

1) ISO 3166 codes and restricting the field as such
2) allow ISO and private codes with a way to distinguish
3) provide one ISO field and one 'Jurisdiction' field

1) is tough and inflexible
2) tends towards non-interoperable
3) is growing the complexity

It depends on what the goal is - what IS the goal for
this field, anyway?

----------------------------------------------------------------------
Chris Smith                                       <[email-masked]>

---

From: Eric Brunner <[email-masked]>
Date: Tue, 11 Jun 2002 15:46:22 -0400

David,

An escape mechanism from a iso3166-constrained interpretation of a series of
two or more octets is fine, assuming that iso3166 was a manditory referent.

When Donald, Bill and I (but mostly Donald and I) went over the equivalent
problem in Domain Name System (DNS) IANA Considerations (BCP 0042), we found
that we could reserve the two-octet label-space without having to cite 3166.

There we were forced to consider the problem of unique identifiers and the
legacy code base that knew the identifiers consisted of 16 contiguous bits,
interpreted as octet-aligned data, and letters-digits-or-hyphen, in ASCII.
We still don't have any basis to judge whether or not the management of the
DNS root was effected one way or another by not citing 3166. We don't appear
to have caused an instance of non-interoperability.

Here we are just attempting to create an identifer with no compactness
properties that force us to use binary labels, or anything less compact
than strings -- the requirement of two octet (ASCII) strings seems to be
foreign to the problem at hand.

The degree of implementation complexity that seperates a two-octet lookup
table with sparce (240) values, and shell-completion isn't compelling.

If the 3166 reference is optional (which is how we solved this problem in
the XML stream for provisioning DNS TLD registries in PROVREG [1]), then
the problem is solved.

Eric

[1]  EPP Contact mapping, Sec. 2.4.1 Street, City, and State or Province
     draft-ietf-provreg-epp-contact-04.txt