[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-trade Home]
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-trade Home]
Powered by eList eXpress LLC