RE: new ECML v 2 requirements from Nokia

[Ronald Duncan <Ronald.Duncan@software.plc.uk>]

Title: RE: new ECML v 2 requirements from Nokia

We are just updating our tax and shipping calculator so this is quite relevant to us at the moment.

 

Currently the ISO codes give us a reasonable number of countries.  However there are a number of different issues.

 

E.g. Isle of Man has different tax implications for shipping from the UK and may have different costs.

 

It does not appear to have an ISO 2 letter or 3 letter code but has a Numerical Code.  The ISO Alpha 3 code does seem more comprehensive than the 2 letter codes however it is not freely available.

http://unstats.un.org/unsd/methods/m49/m49alpha.htm

vs

http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/index.html

 

The ISO codes are easy to find however, I had a quick trawl

through http://www.xcbl.org 

and http://www.oasis-open.org/committees/ubl/

 

and I was not able to find the current Othercountries list which is clearly going to be vital for interoperability.

 

A link would be much appreciated.

 

There are large numbers of principalities and tax havens in the world and a common way of referencing them would be nice.

 

Regards -- Ronald

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: 11 June 2002 16:02
To: 'Chris Smith'; Donald Eastlake 3rd
Cc: Eric Brunner; lauri.piikivi@nokia.com; Chris.Brandt@ernexinc.com; ietf-trade@lists.elistx.com
Subject: RE: new ECML v 2 requirements from Nokia

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:smith@interlog.com]
Sent: Monday, June 10, 2002 9:47 PM
To: Donald Eastlake 3rd
Cc: Eric Brunner; lauri.piikivi@nokia.com; Chris.Brandt@ernexinc.com;
ietf-trade@lists.elistx.com
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                                       <smith@interlog.com>