Re: new ECML v 2 requirements from Nokia

[Donald Eastlake 3rd <dee3@torque.pothole.com>]

Hi,

On Mon, 10 Jun 2002, Eric Brunner wrote:

> Date: Mon, 10 Jun 2002 11:30:42 -0400
> From: Eric Brunner <brunner@world.std.com>
> To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>
> Cc: 'Eric Brunner' <brunner@world.std.com>, lauri.piikivi@nokia.com,
>      Chris.Brandt@ernexinc.com, ietf-trade@lists.elistx.com,
>      brunner@world.std.com
> Subject: Re: new ECML v 2 requirements from Nokia
>
> Donald,
>
> 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?
>
> The Navajo Nation is vastly larger than the Vatican State, Monacco, Pitcarn's
> Island, the Channel Islands, the Sechyelles, and a dozen Pacific Nations ...
> combined. The Pequot Nation is vastly wealthier than some of those also.
>
> To limit the territorial jurisdiction identifiers to the criteria set by the
> DIN makes two-byte comparison easy, but it subordinates use to "states".

The Navajo Nation, etc., are subordinate entities that are "soveriegn"
only to the extent that the US allows. In this regard, it is not clear
to me that they are different from states or territories of the US.
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...

> Tell me how I can use thie protocol if the trading community consists of
> financial clearinghouse operating companies located within the soverign
> indigenous nations of North America (I already know the answer for soverign
> colonial nations).

US law prevails in the cases where the US has decided it is important
enough. When the law can vary and this is important, you would need a
subdesignator under the country code.

> > This protocol will only be interoperable to the extent that field values are
> > well defined. There is nothing wrong with having non-interoperable private
> > values and extensions, but I believe we should strive to have an
> > interoperable core of values.
>
> We shouldn't use iso3166 unless there really is no alternative. Until last
> year you couldn't even find Palestine in 3166.

Whether you like the situation or not, the Palestinian Authority /
Occupied Palestinian Territories is a subordinate sovereignty to Israel
and has just as much sovereignty as Isreal permits, as recent events
have shown.

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, but I'm not convinced it come up much in real life or if
it does, that you can't just figure it out from other parts of the
address. I don't think there is any standard for such extensions and I
don't think the TRADE WG wants to take on defining such a standard.

> Practially speaking, for iso3166 territorial jurisdictions (TJs), implementors
> will use 3166 code. Realistically, implementors for non-3166 TJs will consult
> the TJ for identifiers.

I would note that all the financial card network protocols I know of get
along fine using UN Country numbers, which are pretty much the same as
iso3166 country codes.

> Eric

Donald